[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24201: 25.1.50; TLS connections sometimes hang
From: |
Eli Zaretskii |
Subject: |
bug#24201: 25.1.50; TLS connections sometimes hang |
Date: |
Mon, 24 Jun 2019 22:20:08 +0300 |
> 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.
- bug#24201: 25.1.50; TLS connections sometimes hang, Lars Ingebrigtsen, 2019/06/24
- bug#24201: 25.1.50; TLS connections sometimes hang,
Eli Zaretskii <=
- bug#24201: 25.1.50; TLS connections sometimes hang, Lars Ingebrigtsen, 2019/06/24
- bug#24201: 25.1.50; TLS connections sometimes hang, Lars Ingebrigtsen, 2019/06/25
- bug#24201: 25.1.50; TLS connections sometimes hang, Lars Ingebrigtsen, 2019/06/25
- bug#24201: 25.1.50; TLS connections sometimes hang, Eli Zaretskii, 2019/06/26
- bug#24201: 25.1.50; TLS connections sometimes hang, Lars Ingebrigtsen, 2019/06/27
- bug#24201: 25.1.50; TLS connections sometimes hang, Eli Zaretskii, 2019/06/27
- bug#24201: 25.1.50; TLS connections sometimes hang, Lars Ingebrigtsen, 2019/06/27
- bug#24201: 25.1.50; TLS connections sometimes hang, Eli Zaretskii, 2019/06/28
- bug#24201: 25.1.50; TLS connections sometimes hang, Lars Ingebrigtsen, 2019/06/28
- bug#24201: 25.1.50; TLS connections sometimes hang, Eli Zaretskii, 2019/06/28