bug#24201: 25.1.50; TLS connections sometimes hang

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 24201@debbugs.gnu.org,  eggert@cs.ucla.edu
> Date: Mon, 24 Jun 2019 15:25:52 +0200
> 
> I've now started looking at this again, and is running Emacs under gdb.

Thanks.

> Last night, I got the hang again.  I C-z'd in gdb (i.e., SIGTSTP), and
> then did "finish" until it returned sufficiently that we got back to the
> hang, and the I repeated, the procedure a couple of times, until the
> file "finish" returned to Emacs and Emacs was un-hung.
> 
> These hangs usually last for about a minute or so, with intervention
> with gdb or not, so I would guess that the code stops hanging when the
> peer finally gives up on the connection and hangs up or something.
> 
> Does the output from gdb have any smoking gun about what's making this
> semi-infloop in accept-process-output?

It doesn't loop in accept-process-output, it loops several stack
frames above that.  accept-process-output returns when you type
"finish", so it by itself is not the culprit.

> (gdb) finish
> Run till exit from #0  Ffuncall (nargs=4, args=args@entry=0x7fffffffb420)
>     at eval.c:2826
> 0x0000555555720e60 in exec_byte_code (bytestr=<optimized out>, 
>     vector=<optimized out>, maxdepth=<optimized out>, 
>     args_template=<optimized out>, nargs=nargs@entry=5, args=<optimized out>, 
>     args@entry=0x34) at bytecode.c:633
> 633		    TOP = Ffuncall (op + 1, &TOP);
> Value returned is $13 = (union Lisp_X *) 0x0
> (gdb) finish
> Run till exit from #0  0x0000555555720e60 in exec_byte_code (
>     bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, 
>     args_template=<optimized out>, nargs=nargs@entry=5, args=<optimized out>, 
>     args@entry=0x34) at bytecode.c:633
> 
> ^Z

Each time "finish" doesn't return you have a call to funcall and 2
calls to exec_byte_code above it.  Can you tell what function is being
called by funcall?  It's easy: after you get to that frame, and see
this:

  Ffuncall (nargs=4, args=args@entry=0x7fffffffb420) at eval.c:2826
  2826	  lisp_eval_depth--;
  Value returned is $12 = (union Lisp_X *) 0x0

don't type "finish", but instead do this:

  (gdb) p args[0]
  (gdb) xsymbol

You should see one of the Lisp functions you see in the Lisp
backtrace:

  "accept-process-output" (0xffffb498)
  "network-stream-get-response" (0xffffb728)
  "network-stream-open-starttls" (0xffffbbd8)
  "open-network-stream" (0xffffbec0)
  "nntp-open-connection" (0xffffc3a0)
  "nntp-possibly-change-group" (0xffffca50)
  "nntp-with-open-group-function" (0xffffccf0)
  "nntp-request-article" (0xffffcf60)
  "gnus-request-article" (0xffffd228)
  "gnus-async-prefetch-article" (0xffffd538)
  "apply" (0xffffd648)
  "timer-event-handler" (0xffffd8f8)

Once you see the name of that function, look at its caller's code, and
try to figure out what are the two levels of exec_byte_code above
Ffuncall doing, and through this why they might loop.