GNU bug report logs - #22789
25.1.50; In last master build https connections stop working

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alain Schneble <a.s <at> realize.ch>
Cc: larsi <at> gnus.org, j_l_domenech <at> yahoo.com, 22789 <at> debbugs.gnu.org
Subject: bug#22789: 25.1.50; In last master build https connections stop working
Date: Mon, 07 Mar 2016 19:33:17 +0200

> From: Alain Schneble <a.s <at> realize.ch>
> CC: <larsi <at> gnus.org>, <j_l_domenech <at> yahoo.com>, <22789 <at> debbugs.gnu.org>
> Date: Mon, 7 Mar 2016 18:20:20 +0100
> 
> >>   Could it be a multi-threading issue then?  Multiple threads
> >>   accessing the same socket...
> >
> > Not sure I follow -- are you trying to explain why ioctlsocket doesn't
> > fail as expected, or are you trying to explain some other phenomenon?
> 
> Both.  1) I expected it to (sometime) fail but didn't see it.  2) The
> arbitrary gnutls_handshake failures I observed seem like the socket's
> state is getting corrupted.

I cannot argue with facts.  I'm not sure the ioctlsocket calls are
what causes the failures, but since you say the failures disappear
when we don't, it's a fact that we should accept.

> Do you agree that WSAEventSelect is called from the reader thread and
> the ioctlsocket is called from the main thread?

Yes, of course.

> And AFAIK, these functions are not thread safe...

I don't think this is true.  AFAIK, the WSA* functions are all
thread-safe.

> So I suspect that we ran into a multi-threading issue here, which
> corrupted the socket.  And may have lead to the above mentioned
> issues.

It's possible.  But if you see the problems solved after the change, I
see no reason to continue arguing.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.