On 03/21/2015 03:02 AM, Konstantin Belousov wrote:
On Fri, Mar 20, 2015 at 03:59:52PM +0200, Ivan A. Kosarev wrote:
#12 0x00000008011b428d in malloc_init_hard () at jemalloc_jemalloc.c:698
#13 malloc_init () at jemalloc_jemalloc.c:296
#14 0x0000000801243ea2 in ?? () from /lib/libc.so.7
#15 0x00000008006a5400 in ?? ()
#16 0x000000080089e5b0 in ?? () from /libexec/ld-elf.so.1
#17 0x00007fffffffe0b0 in ?? ()
#18 0x0000000801139d06 in _init () from /lib/libc.so.7
#19 0x00007fffffffe0b0 in ?? ()
The backtrace is strange. Did you compiled malloc with the debugging
symbols, while keep rest of libc without -g ?
I've just added the -g flag to CC_FLAGS in the Makefile and made sure to
install an unstripped version of the .so . I could investigate more on
why the early calls omit debug symbols, if it does any matter.
Does it happen always, on only for the early initialization of the
I'm not sure I understand the whole logic of the initialization process,
but we could put a statement initializing the chunksize variable to 0 to
the beginning of malloc_init_hard() and see if the assertion (or any
other before it) fails. Since my suspicion is that the variable get
random values at base_boot(), the presence of the failure depends on
random factors. For a simple one-line program calling malloc() it is
known to not to fail, of course. I should be able to to more tests on Mon.
It might be related to r276630. Can you test on, say, 10.1 ?
The Tsan tests mentioned below that cause mass (alignment != 0) failures
are known to work fine on 10.1.
<jemalloc>: jemalloc_chunk.c:152: Failed assertion: "alignment != 0"
Here's more of failures of this kind around:
Can you please let me know if the analysis is correct and there's
something to fix about initialization of the variable?
Backtrace looks valid.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"