Re: malloc-related SIGSEGV when cross-building i386 on NetBSD-10.0/amd64

[Taylor R Campbell <campbell+netbsd-tech-userlevel%mumble.net@localhost>]

> Date: Tue, 16 Apr 2024 00:59:31 +0000
> From: Emmanuel Dreyfus <manu%netbsd.org@localhost>
> 
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0xf4bde597 in tsd_fetch_impl (minimal=false, init=true)
>     at /usr/src/external/bsd/jemalloc/lib/../include/jemalloc/internal/tsd.h:270
> 270     return tsd;
> 
> (gdb) bt
> #0  0xf4bde597 in tsd_fetch_impl (minimal=false, init=true)
>     at /usr/src/external/bsd/jemalloc/lib/../include/jemalloc/internal/tsd.h:270
> [...]
> #14 tsd_fetch ()
>     at /usr/src/external/bsd/jemalloc/lib/../include/jemalloc/internal/tsd.h:291
> [...]
> (gdb) disas 0xf4bde597
> [...]
>    0xf4bde591 <+37>:   mov    -0x2d0(%ebx),%ecx
> => 0xf4bde597 <+43>:   mov    %gs:0x0,%esi
>    0xf4bde59e <+50>:   add    %ecx,%esi
> 
> (gdb) info reg        
> [...]
> gs             0x0                 0

Great, thanks!  Can you file a PR with this information so we can use
it to track fixes and pullups?

It would also be great if you could catch a stack trace in a crash
that isn't in a signal handler itself, just to keep the diagnosis
simpler.

It looks like somehow the thread's tls pointer (%gs) is null, but my
guess is that this happens only sometimes, e.g. during involuntary
kernel context switches that involve saving and restoring a trap
frame, which is why it appears to be happening randomly and not
immediately when any process tries to use malloc.