> Date: Tue, 16 Apr 2024 00:59:31 +0000 > From: Emmanuel Dreyfus <m...@netbsd.org> > > 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.
