Re: Use of chunksize before initialization

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Sat, 21 Mar 2015 03:02:18 +0200
On Fri, Mar 20, 2015 at 03:59:52PM +0200, Ivan A. Kosarev wrote:
> Hello everybody,
> 
> The malloc_init_hard() function defined in jemalloc_jemalloc.c, FreeBSD 
> 11 r277486 reads:
> 
> static bool
> malloc_init_hard(void)
> {
>      ...
>      if (base_boot()) {
>          malloc_mutex_unlock(&init_lock);
>          eturn (true);
>      }
> 
>      if (chunk_boot()) {
>          malloc_mutex_unlock(&init_lock);
>          return (true);
>      }
>      ...
> 
> The second call initializes the 'chunksize' global variable defined in 
> jemalloc_chunk.c:
> 
> bool
> chunk_boot(void)
> {
>      /* Set variables according to the value of opt_lg_chunk. */
>      chunksize = (ZU(1) << opt_lg_chunk);
>      assert(chunksize >= PAGE);
>      ...
> 
> However, it seems the first call to base_boot() depends on that variable 
> already:
> 
> (gdb) bt
> #0  thr_kill () at thr_kill.S:3
> #1  0x0000000801241408 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:51
> #2  0x000000000041d817 in __interceptor_raise () at 
> /usr/home/ik/llvm/llvm.current/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:2097
> #3  0x000000080123f969 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
> #4  0x000000000041c5d9 in __interceptor_abort () at 
> /usr/home/ik/llvm/llvm.current/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1851
> #5  0x00000008011a8d64 in __je_chunk_alloc (size=<optimized out>, 
> alignment=<optimized out>, base=<optimized out>, zero=<optimized out>,
>      dss_prec=dss_prec_disabled) at jemalloc_chunk.c:150
> #6  0x00000008011a9bfc in base_pages_alloc (minsize=128) at 
> jemalloc_base.c:35
> #7  __je_base_alloc (size=<optimized out>) at jemalloc_base.c:57
> #8  0x00000008011a9c96 in __je_base_calloc (number=<optimized out>, 
> size=6) at jemalloc_base.c:74
> #9  0x00000008008ae548 in mutex_init (calloc_cb=0x0, mutex=<optimized 
> out>, mutex_attr=<optimized out>) at 
> /usr/src/lib/libthr/thread/thr_mutex.c:145
> #10 _pthread_mutex_init_calloc_cb (mutex=0x801487c90, calloc_cb=0x0) at 
> /usr/src/lib/libthr/thread/thr_mutex.c:229
> #11 0x00000008011a18da in __je_malloc_mutex_init (mutex=0x18744) at 
> jemalloc_mutex.c:97
> #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 ?

Does it happen always, on only for the early initialization of the 
mutexes ?  It might be related to r276630.  Can you test on, say, 10.1 ?

> 
> Note that base_pages() calls chunk_alloc() with chucksize used as the 
> alignment value:
> 
> static bool
> base_pages_alloc(size_t minsize)
> {
>      ...
>      base_pages = chunk_alloc(csize, chunksize, true, &zero,
>          chunk_dss_prec_get());
>      ...
> 
> and the latter tests it against zero:
> 
> void *
> chunk_alloc(size_t size, size_t alignment, bool base, bool *zero,
>      dss_prec_t dss_prec)
> {
>      ...
>      assert(alignment != 0);
>      ....
> 
> so we sometimes we end up with:
> 
> <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.
Received on Sat Mar 21 2015 - 00:02:25 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:56 UTC