[Help-gnutls] Re: Odd issue with gnu-tls 2.6.4 running as a subprocess of emacs-23 on Windows XP
simon at josefsson.org
Tue Apr 14 02:38:03 CEST 2009
Iver Odin Kvello <iverodin at gmail.com> writes:
> Hi, I've continued debugging this problem somewhat more, getting
> somewhat confusing results.
> The first thing I tried was to remove stdin from the call to select in
> cli.c line 735, instead just reading from stdin unconditionally after
> each select timeouts. This actually helped, a bit - earlier, jabber
> would hang waiting for the server to indicate that authentication
> succeeded, but this change fixed that. It now started hanging a bit
> later on, waiting for session initiation to succeed.
> After diverse experiments, I thought of adding a linefeed to each
> message sent. In jabber-conn.el I found that this was already done --
> so I just added *another* linefeed, sending two after each message.
> With my modified copy of cli.c, this actually fixed things, and
> everything worked as it should. I then tried doing this with an
> unmodified cli.c, and to my surprise found that that *didn't* work,
> instead hanging at the session-initiation stage - that is, it actually
> got a bit further than before, but not all the way through.
> Obviously the next step would then be to have jabber.el add *five*
> line-feeds after each message. And of course, that works with the
> standard unmodified gnutls-cli.exe.
> So I think that there is *some* kind of bug going on with reading from
> stdin when run as a subprocess under windows; not entirely connected
> to but not unaffected by the select()-emulation.
Yes, gnutls 2.6.x and earlier uses a broken emulation of select() which
likely does have problems, and there is also some buffering problems
that can result in CRLF confusion.
Gnutls 2.7.x will fix this, but unfortunately there is a small piece
missing to prevent it from working under Windows right now... this is
probably the biggest remaining issue to fix before 2.8.x so it is a
More information about the Gnutls-help