correction: bug report: gcount() returns 0 when socket is read into contents successfully and then enters half-closed state

[Howell Chen]

Some parts of this message have been removed. Learn more about Nabble's security policy.

The problematic line for the specific case is actually 2910:

            Error(errInput, “Could not read from socket”, socket_error);

 

Regards,

 

Howell

 

---

From: Howell Chen
Sent: Monday, September 08, 2008 10:33 AM
To: 'bug-commoncpp@...'
Subject: bug report: gcount() returns 0 when socket is read into contents successfully and then enters half-closed state

 

Hi Commoncpp developer,

 

Playing around commoncpp 1.6.3 code, I met some behavior under following scenario, which I believe as buggy:

 

1.       Peer A and peer B enter a tcp session

2.       A sends some contents to B; if no error is reported (tcp subsystem agree to take over whatever needs to be done to deliver), A closes and exit

3.       meanwhile, in a loop, peer B receive byte streams through the TCPStream::read, after which follows a call of TCPStream::gcount() to know how many bytes the previous read() has read in – a exit condition for the loop is gcound() returns 0, indicating tcp stream has nothing to read and should be closed to release this tcp resource.

 

Here comes the bug: the last TCPStrteam::read() actually reads some bytes before its underlying (socket) read returns 0. The 0 return value would immediately call clear(ios::failbit | rdstate() ) (line 2911, src/csocket.cpp, commoncpp-1.6.3), which in turn resets gcount internal data structure _M_gcount to 0, causing the subsequent TCPStream::gcount() returns the incorrect 0.

 

For a socket read to return 0 is quite normal and legitimate when the peer send FIN and enters the so-called half-close state. TCPStream::read() actually reads correctly all the byte stream that might be queued, but the TCPStream::gcount returning 0 subsequently is definitely conflicting what is expected from a read/gcound with an istream object.

 

Hope this description serves its purpose well.

 

Regards,

 

Howell Chen

_______________________________________________
Bug-commoncpp mailing list
Bug-commoncpp@...
http://lists.gnu.org/mailman/listinfo/bug-commoncpp