Subject: Re: bug#76970: 31.0.50; master emacs crash with stack overflow

From: Aaron Zeng <[email-masked]>
Date: Mon, 23 Jun 2025 16:06:52 -0400

On Sun, Jun 22, 2025 at 3:15 AM Eli Zaretskii <[email-masked]> wrote:

> This is possible, but we have no evidence to think this is what
> happened.  Moreover, the main thread didn't yet return from
> pthread_mutex_unlock when SIGPROF is delivered:
>
> >> #4  0x00000000005c3f27 in backtrace_top_function () at eval.c:4294
> >>         pdl = <optimized out>
> >> #5  0x000000000063a0da in add_sample (plog=0xcdf060 <cpu>, count=1436)
> at lisp.h:1192
> >> #6  0x0000000000557604 in deliver_process_signal (sig=27,
> handler=0x63a440 <handle_profiler_signal>) at sysdep.c:1758
> >>         old_errno = 11
> >>         on_main_thread = true
> >> #7  0x00007fbda4812970 in <signal handler called> () at
> /lib64/libpthread.so.0
> >> #8  0x00007fbda481154a in __lll_unlock_wake () at /lib64/libpthread.so.0
> >> #9  0x00007fbda480c2e6 in __pthread_mutex_unlock_usercnt () at
> /lib64/libpthread.so.0
> >> >> #10 0x000000000063af2f in release_global_lock () at thread.c:621
>
> Is the global lock already released at this point? are other threads
> allowed to run?  What is __lll_unlock_wake about -- doesn't it wake
> some other thread?  If it did not yet do so, the other thread couldn't
> have been running.
>
> IOW, we need backtrace from all the threads, not just from the main
> thread, to draw any definitive conclusions.
>

I applied your patch from the master branch and got a segfault again, but
it has a different
top frame.  I have attached a backtrace generated with [thread apply all bt
full].  In this one,
I do not see __lll_unlock_wake appear at all.

This is from Emacs compiled at
revision 991d3ad80a37a1cf8951d2607eb5f7544f968e93.

It seems it is possible for current_thread to be set to NULL by the dying
thread,
during backtrace_top.