GNU bug report logs - #34341
26.1; url-retrieve-synchronously returns blank buffer

Previous Next

Full log

Message #16 received at 34341 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Laurent Charignon <l.charignon <at> gmail.com>
Cc: 34341 <at> debbugs.gnu.org
Subject: Re: bug#34341: 26.1; url-retrieve-synchronously returns blank buffer
Date: Sat, 04 May 2019 11:18:30 -0400

Laurent Charignon <l.charignon <at> gmail.com> writes:

> #### Context
>
> The symptom of this issue first came up in the context of `ghub`, a package
> that offers interfacing with Github from emacs (issue:
> https://github.com/magit/ghub/issues/81).
>
> Multiple users of the `ghub` package started observing that
> synchronously retrieving content from the github API through ghub
> returned blank responses.

> (switch-to-buffer (url-retrieve-synchronously "
> https://api.github.com/users/charignon/repos")
>                   (buffer-string))

> From bisecting, I know that the fix is in between 191a5568db (working) and
> 2a3bd6798e96708 (not working). It is hard to pinpoint further due to
> segfaults that were introduced then fixed in this range. My best guess is
> that "Fix unlikely races with GnuTLS, datagrams" (e87e6a24c4) resolved this.

I can confirm that cherrypicking this commit fixes the problem on my
Arch box which has gnutls 3.6.7 (doesn't occur at all on my Debian box
with gnutls 3.5.8).

Since the only recourse for users hitting is rebuilding --without-gnutls
or (advice-add 'gnutls-available-p :override #'ignore) which falls back
to the obsolete tls.el, I'd say this is important enough to backport to
emacs-26.  I'll do that in a couple of days if there are no objections.

Previous Next

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