Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Feb 2017 12:25:11 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-amd64@FreeBSD.org
Subject:   [Bug 217138] head (e.g.) -r313783 sh vs. jemalloc asserts: include/jemalloc/internal/tsd.h:687: Failed assertion: "tsd_booted"
Message-ID:  <bug-217138-6-1QVX8KBZ6o@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-217138-6@https.bugs.freebsd.org/bugzilla/>
References:  <bug-217138-6@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217138

--- Comment #1 from Mark Millard <markmi@dsl-only.net> ---
(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 "tsd_booted":

<jemalloc>: /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:687:
Failed assertion: "tsd_booted"

A back trace is:

(lldb) bt
* thread #1: tid =3D 100194, 0x0000000040554e18 libc.so.7`_thr_kill + 8, na=
me =3D
'sh', stop reason =3D signal SIGABRT
  * frame #0: 0x0000000040554e18 libc.so.7`_thr_kill + 8
    frame #1: 0x0000000040554ddc libc.so.7`__raise(s=3D6) + 64 at raise.c:52
    frame #2: 0x0000000040554d50 libc.so.7`abort + 84 at abort.c:65
    frame #3: 0x0000000040528790 libc.so.7`__je_tsd_fetch [inlined]
__je_tsd_get + 248 at tsd.h:687
    frame #4: 0x000000004052876c libc.so.7`__je_tsd_fetch [inlined]
__je_tsd_fetch_impl(init=3Dtrue) at tsd.h:692
    frame #5: 0x000000004052876c libc.so.7`__je_tsd_fetch + 212 at tsd.h:717
    frame #6: 0x0000000040550cc0 libc.so.7`__free(ptr=3D0x0000000040a17720)=
 + 64
at jemalloc_jemalloc.c:2011
    frame #7: 0x0000000000411328 sh`ckfree(p=3D<unavailable>) + 32 at
memalloc.c:88
    frame #8: 0x0000000000407cd8 sh`clearcmdentry + 76 at exec.c:505
    frame #9: 0x0000000000406bfc sh`evalcommand(cmd=3D<unavailable>,
flags=3D<unavailable>, backcmd=3D<unavailable>) + 3476 at eval.c:1182
    frame #10: 0x0000000000405570 sh`evaltree(n=3D0x0000000040a1cde8,
flags=3D<unavailable>) + 212 at eval.c:290
    frame #11: 0x000000000041105c sh`cmdloop(top=3D<unavailable>) + 252 at
main.c:231
    frame #12: 0x0000000000410ed0 sh`main(argc=3D<unavailable>,
argv=3D<unavailable>) + 660 at main.c:178
    frame #13: 0x0000000000402f30 sh`__start + 360
    frame #14: 0x0000000040434658 ld-elf.so.1`.rtld_start + 24 at
rtld_start.S:41

It appears that setvar was not used but clearcmdentry
(indirectly) gets the same sort of problem when this
happens:

(lldb) up 9
frame #9: 0x0000000000406bfc sh`evalcommand(cmd=3D<unavailable>,
flags=3D<unavailable>, backcmd=3D<unavailable>) + 3476 at eval.c:1182
   1179         if (lastarg)
   1180                 setvar("_", lastarg, 0);
   1181         if (do_clearcmdentry)
-> 1182                 clearcmdentry();
   1183 }

--=20
You are receiving this mail because:
You are on the CC list for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-217138-6-1QVX8KBZ6o>