[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Strange bug, help needed



On Sun, Jun 22, 2008 at 03:21:38PM +0200, Mike Hommey wrote:
> Hi,
> 
> 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:
>   free(prev_r2t_trans);
> 
> 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
> LD_PRELOAD=/usr/lib/iceweasel/xulrunner/libjemalloc.so.
> The same crash happens if I directly link libjemalloc to xulrunner-stub,
> revove the re-execution hack and run it with the appropriate
> LD_LIBRARY_PATH.
> 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 
screwed.

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
library.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net


Reply to: