On Sun, Jun 22, 2025 at 3:15 AM Eli Zaretskii 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 = > >> #5 0x000000000063a0da in add_sample (plog=0xcdf060 , count=1436) > at lisp.h:1192 > >> #6 0x0000000000557604 in deliver_process_signal (sig=27, > handler=0x63a440 ) at sysdep.c:1758 > >> old_errno = 11 > >> on_main_thread = true > >> #7 0x00007fbda4812970 in () 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.