[Bug 217138] head (e.g.) -r313783 sh vs. jemalloc asserts: include/jemalloc/internal/tsd.h:687: Failed assertion: "tsd_booted"

2017-02-18 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217138 Mark Millard changed: What|Removed |Added Hardware|amd64 |arm64

[Bug 217138] head (e.g.) -r313783 sh vs. jemalloc asserts: include/jemalloc/internal/tsd.h:687: Failed assertion: "tsd_booted"

2017-02-18 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217138 --- Comment #4 from Mark Millard --- I got a somewhat different trace back this time: (lldb) bt * thread #1: tid = 100105, 0x40554e18 libc.so.7`_thr_kill + 8, name = 'sh', stop reason = signal SIGABRT *

[Bug 217138] head (e.g.) -r313783 sh vs. jemalloc asserts: include/jemalloc/internal/tsd.h:687: Failed assertion: "tsd_booted"

2017-02-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217138 --- Comment #3 from Mark Millard --- Before starting a round of updates to a newer version of head I got a couple of sh core dumps that showed the same sort of failures. But in these I'd added recording the pid that

[Bug 217138] head (e.g.) -r313783 sh vs. jemalloc asserts: include/jemalloc/internal/tsd.h:687: Failed assertion: "tsd_booted"

2017-02-16 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217138 --- Comment #2 from Mark Millard --- If one is going to look into this in a amd64 context it is important to be using head -r313772 or later in order to avoid fork sometimes not preserving the stack pointer on the

[Bug 217138] head (e.g.) -r313783 sh vs. jemalloc asserts: include/jemalloc/internal/tsd.h:687: Failed assertion: "tsd_booted"

2017-02-16 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217138 --- Comment #1 from Mark Millard --- (In reply to Mark Millard from comment #0) It turns out that the sh failure during buildworld also gets to __je_tsd_get (but a different way) and then fails the same assertion for