bug#30364: 26.0.91; thread crash on macos

[Aaron Jensen]

On Sun, Feb 18, 2018 at 10:25 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 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.

FWIW, this happens even if I only have 1 thread active. The benchmark
100 is just for me to more easily repro it.

Here's a trace from doing one thread at a time:

https://gist.github.com/aaronjensen/cb91f0c7f63a28335a9cea3c88037d59

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

I can probably look into it at some point if you think it is still
relevant given above.

> 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.

Perhaps I'm still doing something wrong:

(lldb) frame select 2449
frame #2449: 0x000000010029a4b7 emacs`Ffuncall + 759
emacs`Ffuncall:
    0x10029a4b7 <+759>: movq   %rax, -0x38(%rbp)
    0x10029a4bb <+763>: jmp    0x10029a528               ; <+872>
    0x10029a4c0 <+768>: movl   $0xc1, %edi
    0x10029a4c5 <+773>: movq   -0x28(%rbp), %rax
(lldb) p args
error: use of undeclared identifier 'args'

I'm not seeing sources, so I probably need to figure out how to load symbols.

> 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.

Got it.

Thanks,
Aaron