Re: Strange bug, help needed
On Sun, Jun 22, 2008 at 03:21:38PM +0200, Mike Hommey wrote:
> I am hitting a very strange bug, and my knowledge is limited to
> understand all the ramifications of the issue.
> The bug itself, and how to reproduce it:
> Run iceweasel (3.0~rc2-2) and keep the window open
> Run iceweasel again, which will open a new window in the existing
> iceweasel, and... segfault.
> I only could reproduce this on amd64 (and not on i386, though i haven't
> tested other architectures). I couldn't first reproduce this in a clean
> chroot, until I installed bug-buddy (though removing it afterwards
> doesn't make it work again. Some dependency bug-buddy pulls must be
> catalyzing the problem.
> When first debugging this, I could see the crash happening after main()
> was returned from..
> After installing libc6-dbg and a DEB_BUILD_OPTIONS=nostrip rebuilt
> libselinux1, I could get a somewhat significant backtrace:
> #0 0x00007f9d67339160 in ptmalloc_init () from /lib/libc.so.6
> #1 0x00007f9d6733ce37 in memalign_hook_ini () from /lib/libc.so.6
> #2 0x00007f9d67d437d7 in __tls_get_addr () from /lib64/ld-linux-x86-64.so.2
> #3 0x00007f9d6010329d in fini_context_translations () at setrans_client.c:211
> #4 0x00007f9d600f657f in __do_global_dtors_aux () from /lib/libselinux.so.1
> #5 0x0000000000401110 in operator new () #6 0x00007fff6ff4f210 in ?? ()
> #7 0x00007f9d60104ab1 in _fini () from /lib/libselinux.so.1
> #8 0x0000000000000053 in ?? ()
> #9 0x00007f9d67d40e04 in _dl_fini () from /lib64/ld-linux-x86-64.so.2
> setrans_client.c:211 reads:
> Now, it may seem strange that malloc is being initialized at exit()
> time, and that is part of what is strange with this bug.
> The fact is, xulrunner-stub, which is what iceweasel runs, actually,
> re-executes itself with
> The same crash happens if I directly link libjemalloc to xulrunner-stub,
> revove the re-execution hack and run it with the appropriate
> So this is not LD_PRELOAD related.
> So, for some reason, libselinux.so.1 is trying to run free() from libc
> instead of libjemalloc.
I think that is actually the problem. If memory is allocated with
libjemalloc, and then freed (or the reverse) with glibc, you're
The GNU libc may use malloc internally, for example I am sure
linuxthreads does that, I don't know about NPTL. Also, as you pointed
other libraries may directly call malloc or free.
You must make sure all calls to malloc are then freed by the same
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' email@example.com | firstname.lastname@example.org
`- people.debian.org/~aurel32 | www.aurel32.net