This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: PLEASE TEST: New implementation of blocking socket I/O
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.