in nontrivial programs, malloc/calloc are already called before "main" is invoked

[timo]

For example, here's a traceback at a random spot before main that calls calloc

#1  0x00007ffff7fdd3d4 in _dl_new_object (
    realname=realname@entry=0x7ffff7fc93e0 "/lib64/librt.so.1", 
    libname=libname@entry=0x7ffff77472db "librt.so.1", type=type@entry=1, 
    loader=loader@entry=0x7ffff7fc8000, mode=mode@entry=0, nsid=nsid@entry=0) at dl-object.c:89
#2  0x00007ffff7fd8857 in _dl_map_object_from_fd (name=name@entry=0x7ffff77472db "librt.so.1", 
    origname=origname@entry=0x0, fd=3, fbp=fbp@entry=0x7fffffffd780, 
    realname=0x7ffff7fc93e0 "/lib64/librt.so.1", loader=loader@entry=0x7ffff7fc8000, l_type=1, 
    mode=0, stack_endp=0x7fffffffd778, nsid=0) at dl-load.c:999
#3  0x00007ffff7fda92b in _dl_map_object (loader=0x7ffff7fc8000, name=0x7ffff77472db "librt.so.1", 
    type=1, trace_mode=0, mode=<optimized out>, nsid=<optimized out>) at dl-load.c:2230
#4  0x00007ffff7fdf485 in openaux (a=a@entry=0x7fffffffdd90) at dl-deps.c:64
#5  0x00007ffff7feccfe in _dl_catch_exception (exception=exception@entry=0x7fffffffdd70, 
    operate=operate@entry=0x7ffff7fdf450 <openaux>, args=args@entry=0x7fffffffdd90)
    at dl-error-skeleton.c:208
#6  0x00007ffff7fdf8c3 in _dl_map_object_deps (map=map@entry=0x7ffff7ffe140, 
    preloads=<optimized out>, npreloads=npreloads@entry=0, trace_mode=trace_mode@entry=0, 
    open_mode=open_mode@entry=0) at dl-deps.c:248
#7  0x00007ffff7fd4e91 in dl_main (phdr=<optimized out>, phnum=<optimized out>, 
    user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:1799
#8  0x00007ffff7febc8b in _dl_sysdep_start (start_argptr=start_argptr@entry=0x7fffffffe520, 
    dl_main=dl_main@entry=0x7ffff7fd3450 <dl_main>) at ../elf/dl-sysdep.c:252
#9  0x00007ffff7fd2fac in _dl_start_final (arg=0x7fffffffe520) at rtld.c:447
#10 _dl_start (arg=0x7fffffffe520) at rtld.c:537
#11 0x00007ffff7fd2118 in _start () from /lib64/ld-linux-x86-64.so.2

https://github.com/FooBarWidget/heap_dumper_visualizer - this tool uses objdump to find the offset of main_arena in libc.so and then finds libc.so in the /proc/pid/maps and bases all its calculations on that, but something in there is incompatible with latest glibc

[timo]

I grabbed the output of sbrk(0) before the first time calloc is called (also in _dl_new_object) and wrote it into the ptm2v_info struct in heap_init manually (with gdb); then i tried to dump with ALL_FLAGS, and got

#0  heap_view (info=0x4052d0, flags=..., array_of_inuse_chunks=array_of_inuse_chunks@entry=0x0, 
    len_array_of_inuse_chunks=len_array_of_inuse_chunks@entry=0, 
    array_of_free_chunks=array_of_free_chunks@entry=0x0, 
    len_array_of_free_chunks=len_array_of_free_chunks@entry=0, fd=<optimized out>)
    at src/heapview.c:76
76				print_mem((addr_t)i, (addr_t)(*i));
(gdb) list
71			fprintf(__PRINTING_FILE, "\n----- Heap Dump -----\n");
72			for (addr_t i = info->heap_base;
73				i < info->main_arena->top;
74				i++) // incrementing the address
75			{
76				print_mem((addr_t)i, (addr_t)(*i));
77			}
78		}
79	
80		// Dump the main_arena variable
(gdb) print i
$8 = (addr_t) 0x2a38000
(gdb) print info->heap_base
$9 = (addr_t) 0x405000
(gdb) print info->main_arena->top
$10 = (mchunkptr) 0x7ffff76c4e00 <main_arena+1056>

the last output from the dumping process that isn't (nil) was this line 0x0000000002a9df58 - 0x00000000000020b1

before that there's a boatload of nils, and before that bunch of nils, it looks like this:

	0x0000000002a95a98 - 0x0090005000000001
	0x0000000002a95aa0 - 0x000000000047a6a0
	0x0000000002a95aa8 - (nil)
	0x0000000002a95ab0 - 0x0000000000ae1030
	0x0000000002a95ab8 - 0x00000000010707a0
	0x0000000002a95ac0 - 0x0000000000011d00
	0x0000000002a95ac8 - 0x0000000000011d01
	0x0000000002a95ad0 - 0xffffffffffffffff
	0x0000000002a95ad8 - 0x0000000000610e90
	0x0000000002a95ae0 - 0x000000000107b700
	0x0000000002a95ae8 - 0x000000000047c960
	0x0000000002a95af0 - 0x000000000047c960
	0x0000000002a95af8 - 0x000000000047c960
	0x0000000002a95b00 - (nil)
	0x0000000002a95b08 - (nil)
	0x0000000002a95b10 - 0x0000000001070700
	0x0000000002a95b18 - 0x0000000000995050
	0x0000000002a95b20 - (nil)

i haven't actually looked closely, so i'm not sure if a 1 at the very end of these numbers is a sign of trouble or not

[timo]

and just for completeness' sake, here's the heap line in /proc/pid/maps:

00405000-02aa0000 rw-p 00000000 00:00 0                                  [heap]
7ffff0000000-7ffff0839000 rw-p 00000000 00:00 0

[timo]

sorry for "liveblogging" and spamming this issue with lots of comments; here's some more findings:

having a "wrong" heap base doesn't seem to cause crashes — at least not if there's a check for tcache->counts[i] > 0 before recursing into __print_tcache_entry so that it doesn't segfault there

i haven't been able to actually look at the output much, since it's absolutely massive, but i'd appreciate some guidance as to whether these fixes make any sense or are just giving me bogus data that "at least doesn't crash".