bug#30364: 26.0.91; thread crash on macos

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sun, 18 Feb 2018 09:15:11 -0800
> Cc: Noam Postavsky <npostavs@gmail.com>, 30364@debbugs.gnu.org, 
>       Noam Postavsky <npostavs@users.sourceforge.net>, Alan Third 
> <alan@idiocy.org>
> 
> Thanks, I believe this is the full trace ("bt all" is all of the
> threads and "crashing thread" is just the crashing thread):
> 
> https://gist.github.com/aaronjensen/2c765cfd08556f570a5b78b4c5f8e866

Ah, okay.  I see I've misinterpreted the reason for the crash: the
thread that crashes is the one that does GC.  And since GC is deeply
recursive, and you have 120 - 26 + 1 = 95 other threads all waiting
for the global lock, the first hypothesis I have is that the thread
which GCs hits stack overflow, because the other 95 threads use up (or
reserve) too much stack space.

Can you or someone else who knows about Darwin figure out what are the
limitations on stack space in multithreaded programs on macOS?

> > For the first issue, you will have to evaluate expressions manually,
> > unfortunately, as LLDB doesn't support canned command sequences that
> > we define in src/.gdbinit for GDB.  You will find some starting point
> > here:
> >
> >   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30320#44
> >   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30320#47
> >   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30320#50
> 
> I couldn't figure out how to do this. Nothing I do puts "args" in
> scope, so I'm not sure what I'm doing wrong.

You need to make the frame which calls Ffuncall current first.  Here's
one such frame:

  frame #2434: 0x000000010029a29e emacs`Ffuncall + 222

You will see in the sources that Ffuncall's first argument is the
args[] array.

However, since the crash is in GC, it's not important to see the Lisp
backtrace, as GC can be triggered by almost any Lisp code.