Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Mar 2015 11:20:26 +0200
From:      "Ivan A. Kosarev" <ivan@ivan-labs.com>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        freebsd-current@freebsd.org, Ed Maste <emaste@freebsd.org>
Subject:   Re: Use of chunksize before initialization
Message-ID:  <550D37DA.7060105@ivan-labs.com>
In-Reply-To: <20150321010218.GD2379@kib.kiev.ua>
References:  <550C27D8.2010105@ivan-labs.com> <20150321010218.GD2379@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help

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
> mutexes ?

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:
>
> http://lab.llvm.org:8011/builders/sanitizer_x86_64-freebsd/builds/4758/steps/make-check-tsan/logs/stdio
>
> 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.

Thanks.

-- 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?550D37DA.7060105>