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@gnu.org'
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@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-commoncpp
