bug#24201: 25.1.50; TLS connections sometimes hang

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 24201@debbugs.gnu.org,  eggert@cs.ucla.edu
> Date: Tue, 25 Jun 2019 23:57:35 +0200
> 
> (gdb) finish
> Run till exit from #0  0x0000555555721250 in exec_byte_code (
>     bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized 
> out>, 
>     args_template=<optimized out>, nargs=nargs@entry=3, args=<optimized out>, 
>     args@entry=0x31) at bytecode.c:633
> Ffuncall (nargs=4, args=args@entry=0x7fffffffb770) at eval.c:2826
> 2826    lisp_eval_depth--;
> Value returned is $38 = (union Lisp_X *) 0x0
> (gdb) p args[0]
> $39 = XIL(0x1401750)
> (gdb) xsymbol 
> $40 = (struct Lisp_Symbol *) 0x555557199570
> "network-stream-get-response"

OK, so that Ffuncall calls network-stream-get-response.  the next
question is what Lisp code runs 2 stack frames above, i.e. which Lisp
code calls some other Lisp code, which calls
network-stream-get-response?  Can you spot that?  The offending code
should be somewhere in network-stream-get-response or functions it
calls.

Once we identify the Lisp code which loops, we need to try to figure
out why it loops.

> And upon continuing, Emacs un-stuck with the following message:
> 
> Error running timer ‘gnus-async-prefetch-article’: (error "Server closed 
> connection")

So probably we loop until the other side closes the connection?