PLEASE TEST: New implementation of blocking socket I/O

Corinna Vinschen vinschen@redhat.com
Wed Mar 31 10:07:00 GMT 2004


On Mar 30 20:53, Pierre A. Humblet wrote:
> On Tue, 30 Mar 2004 11:35:39 +0200, Corinna Vinschen wrote:
> > Any more debugging information? 
> 
> The snapshot of yesterday gave the same results.
> 
>   196 2755602 [main] cvs 621789 writev: writev (3, 0x7DE810, 1)
>  3678 2759280 [main] cvs 621789 writev: 310663 = write (3, 0x7DE810, 1),
> errno 2
>  2321 2761601 [main] cvs 621789 sig_dispatch_pending: exit_state 0, cur
> thread id 0xFFF685DF, sigtid 0xFFF5D6F7, sigq.start.next 0x0
>   593 2762194 [main] cvs 621789 __set_errno: int
> __check_invalid_read_ptr_errno(const void*, unsigned int):214 val 14
>   171 2762365 [main] cvs 621789 writev: -1 = write (3, 0x7DE810, 1), errno 14
> 
> Note the 310663 = write (3, 0x7DE810, 1). 
> 
> That's unlikely. Seeing that reminded me that compiler warnings had
> flashed by, and I recompiled likely culprits.
> 
> /../../../src/winsup/cygwin/fhandler_socket.cc:719: warning: `int res'
> might be used uninitialized in this function
> ../../../../src/winsup/cygwin/fhandler_socket.cc: In member function `int
> fhandler_socket::recvmsg(msghdr*, int, int)':
> [...]
> For example in recvfrom, it looks like res is left unset when
> !wsock_evt.prepare().
> I initialized them to SOCKET_ERROR, but still no luck.
>  310679 = write (3, 0x7DE810, 1)
> Please have a look. 

Grrr, gcc doesn't emit these warnings with optimization off.

However, it's unlikely the cause since a failing wsock_event::prepare()
would probably have printed an error message in the strace output.
Well, not if WSACreateEvent fails (but why should it?).  I've checked
in a fix which always prints an error message now if prepare fails.

All four functions now initialized res to SOCKET_ERROR but nothing
changed.  I'm still unable to reproduce that problem, neither with nor
without this change.  Various CVS repositories already hate my box.

What about this:

> Can somebody of you step this through to find the cause?  It really
> doesn't involve much code.  Everything which is important happens in
> the affected fhandler_socket recv/send call ( either one of recvfrom,
> recvmsg, sendto, sendmsg) and in wsock_event::wait.

?

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.



More information about the Cygwin-developers mailing list