Re: Use of chunksize before initialization

On Mon, Mar 23, 2015 at 01:50:26PM +0200, Ivan A. Kosarev wrote:
> 
> On 03/21/2015 11:31 PM, Konstantin Belousov wrote:
> > On Sat, Mar 21, 2015 at 11:20:26AM +0200, Ivan A. Kosarev wrote:
> >> 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.
> > I want to understand at what stage of the initialization the access happens.
> > This is why I want to see the complete backtrace.
> 
> It is jemalloc_constructor() that calls malloc_init(), so it should be 
> called directly by the loader.

Do you mean rtld by loader ? Dynamic linker does not explicitely call
into libc. The possible situations when such call occurs, is either
execution of the initializers, or calls into the libthr-provided rtld
locks, where libthr itself calls malloc to allocate the lock's backing
store. The appearance of _init on the unparsed stack is indicative, but
not conclusive, since gdb shows the nearest dynamic symbol, which could
be _init just by chance.

I need to know exact sequence of events causing the problem.
Or, in other words, I cannot debug by retelling.