socket.is_open returning false when it is in use

[Gonzalo Garramuno]

I have a problem with my program and I traced it to socket.is_open which
returns as closed even while the connection is active in my server
program. The client, however, can still communicate with that
supposedly closed socket. The program is similar to the timeouts
example. I can post all the source code if needed.

[Igor R]

Post by Gonzalo Garramuno
I have a problem with my program and I traced it to socket.is_open which
returns as closed even while the connection is active in my server program.
The client, however, can still communicate with that supposedly closed
socket. The program is similar to the timeouts example. I can post all the
source code if needed.

is_open() merely checks whether the socket has a valid handle
(descriptor), so it can be "false positive", but can't be "false
negative". Show some code - perhaps you've got a race-condition?

[Gonzalo Garramuño]

Post by Igor R

Post by Gonzalo Garramuno
I have a problem with my program and I traced it to socket.is_open which
returns as closed even while the connection is active in my server program.
The client, however, can still communicate with that supposedly closed
socket. The program is similar to the timeouts example. I can post all the
source code if needed.

is_open() merely checks whether the socket has a valid handle
(descriptor), so it can be "false positive", but can't be "false
negative". Show some code - perhaps you've got a race-condition?

Here is the code (won't compile, thou). It is just for reviewing purposes.

[Gonzalo Garramuno]

And here are the logs of what I see:

[Igor R]

Well, the only way to get is_open() == false is to close the socket,
but according to your logs you don't get to stop() function. This's
really strange and I don't have any idea at this point. Maybe the
tcp_session object gets destroyed? Ata a glance, that doesn't seem to
be the case, but try putting some ptint-out in ~tcp_session().
Besides, print socket_.native_handle() every time you access the
socket (read/write/check/close).

[Gonzalo Garramuno]

Post by Igor R
Well, the only way to get is_open() == false is to close the socket,
but according to your logs you don't get to stop() function. This's
really strange and I don't have any idea at this point. Maybe the
tcp_session object gets destroyed? Ata a glance, that doesn't seem to
be the case, but try putting some ptint-out in ~tcp_session().
Besides, print socket_.native_handle() every time you access the
socket (read/write/check/close).

I did both things. The destructor never gets called. The native socket
changes from 24 to -1 (which I guess it means it is also wrong).

[Igor R]

Post by Gonzalo Garramuno
I did both things. The destructor never gets called. The native socket
changes from 24 to -1 (which I guess it means it is also wrong).

-1 means "invalid descriptor", and this is actually the point where
is_open() would return false. But did you spot the moment where it
changes to -1?

[Gonzalo Garramuno]

Post by Igor R

Post by Gonzalo Garramuno
I did both things. The destructor never gets called. The native socket
changes from 24 to -1 (which I guess it means it is also wrong).

-1 means "invalid descriptor", and this is actually the point where
is_open() would return false. But did you spot the moment where it
changes to -1?

It changes when I call the send method which is virtual.
Nothing in the code changes it.

[Gonzalo Garramuno]

Post by Igor R

Post by Gonzalo Garramuno
I did both things. The destructor never gets called. The native socket
changes from 24 to -1 (which I guess it means it is also wrong).

-1 means "invalid descriptor", and this is actually the point where
is_open() would return false. But did you spot the moment where it
changes to -1?

I cannot find what changes it to -1. I put some print statements in
boost asio, and I got the following log, which is very strange.
The following line appears twice at the beginning when it should appear
once, I think.

0x7f1f180010f8 >>>>>>>>>>>> construct socket is now invalid -1

[Juan Ramírez]

What about the function client_thread() ?

The ioservice has no worker attached to it: I think the run() function is
returning earlier because of that, and then the client is destroyed
(closing the socket on its way)?

Can you try to put some log at the beginning and at the end of the function?


__________
Saludos!
Juan

Post by Gonzalo Garramuno
I did both things. The destructor never gets called. The native socket

Post by Gonzalo Garramuno
changes from 24 to -1 (which I guess it means it is also wrong).

-1 means "invalid descriptor", and this is actually the point where
is_open() would return false. But did you spot the moment where it
changes to -1?

I cannot find what changes it to -1. I put some print statements in boost
asio, and I got the following log, which is very strange.
The following line appears twice at the beginning when it should appear
once, I think.
0x7f1f180010f8 >>>>>>>>>>>> construct socket is now invalid -1
_______________________________________________
Boost-users mailing list
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Gonzalo Garramuno]

Post by Juan Ramírez
What about the function client_thread() ?
The ioservice has no worker attached to it: I think the run() function
is returning earlier because of that, and then the client is destroyed
(closing the socket on its way)?

The run function does not return early. I placed some print statements
nevertheless which point to all working fine.
The problem is not in the client but in the server.
The client never closes the socket. The server closes it randomly and
fails to send data. But then it can reconnect itself if the client
sends data.
It is a weird behavior.

[Gonzalo Garramuno]

Post by Igor R

Post by Gonzalo Garramuno
I did both things. The destructor never gets called. The native socket
changes from 24 to -1 (which I guess it means it is also wrong).

-1 means "invalid descriptor", and this is actually the point where
is_open() would return false. But did you spot the moment where it
changes to -1?

One thing that I noticed about my code is that bind is never used, only
the acceptor. I'm not sure how it is used on the server side.

[Gonzalo Garramuno]

Post by Gonzalo Garramuno
One thing that I noticed about my code is that bind is never used,
only the acceptor. I'm not sure how it is used on the server side.

Never mind that. The constructor of the acceptor calls bind and listen.