socket.is_open returning false when it is in use
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.
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?
El 08/12/2012 04:55 a.m., Igor R escribió:
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.
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).
On 09/12/12 06:48, Igor R wrote:
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).
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?
On 09/12/12 11:55, Igor R wrote:
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.
On 09/12/12 11:55, Igor R wrote:
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
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 On Mon, Dec 24, 2012 at 11:09 PM, Gonzalo Garramuno <ggarra13@gmail.com>wrote:
On 09/12/12 11:55, Igor R wrote:
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
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 26/12/12 11:00, Juan Ramírez wrote:
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.
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
On 09/12/12 11:55, Igor R wrote: the acceptor. I'm not sure how it is used on the server side.
participants (4)
-
Gonzalo Garramuno -
Gonzalo Garramuño
-
Igor R -
Juan Ramírez