bug-gnulib
[Top][All Lists]
Advanced

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

Re: Hanging conftest


From: Siddhesh Poyarekar
Subject: Re: Hanging conftest
Date: Thu, 28 Nov 2013 10:30:20 +0530
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Nov 27, 2013 at 10:27:20AM -0700, Eric Blake wrote:
> [adding glibc]
> 
> On 11/27/2013 09:58 AM, Michal Privoznik wrote:
> > Hey guys,
> > 
> > I've just discovered a bug, well a hang in conftest. This is what I ran:
> > 
> > libvirt.git $ git clean -fxd; ./autogen.sh --system
> > 
> > and all looked good until this:
> > 
> > checking whether readlink signature is correct... yes
> > checking whether readlink handles trailing slash correctly... yes
> > checking for working re_compile_pattern... 
> > 
> > When the configure script hang and didn't continue. Attaching a debugger to 
> > hanging conftest process showed:
> > 
> 
> > __lll_lock_wait_private () at 
> > ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:93
> > 93      ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file 
> > or directory.
> > (gdb) bt
> > #0  __lll_lock_wait_private () at 
> > ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:93
> > #1  0x0000003274e7fbd3 in _L_lock_11326 () at malloc.c:5236
> > #2  0x0000003274e7dd55 in __GI___libc_malloc (bytes=53) at malloc.c:2921
> 
> Sounds like glibc is trying to obtain the malloc lock...
> 
> > #3  0x0000003274a0533a in local_strdup (s=0x7feab7a0bf21 
> > "/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1") at dl-load.c:162
> > #4  0x0000003274a08588 in _dl_map_object (address@hidden, address@hidden 
> > "libgcc_s.so.1", address@hidden, address@hidden, address@hidden, 
> > nsid=<optimized out>)
> >     at dl-load.c:2249
> > #5  0x0000003274a12a2c in dl_open_worker (address@hidden) at dl-open.c:225
> > #6  0x0000003274a0e8c4 in _dl_catch_error (address@hidden, address@hidden, 
> > address@hidden, address@hidden <dl_open_worker>, 
> >     address@hidden) at dl-error.c:178
> > #7  0x0000003274a124b1 in _dl_open (file=0x3274f60e30 "libgcc_s.so.1", 
> > mode=-2147483647, caller_dlopen=<optimized out>, nsid=-2, argc=1, 
> > argv=0x7fff58d2c9d8, env=0x7fff58d2c9e8) at dl-open.c:639
> > #8  0x0000003274f1b202 in do_dlopen (address@hidden) at dl-libc.c:89
> > #9  0x0000003274a0e8c4 in _dl_catch_error (objname=0x7fff58d2b9c0, 
> > errstring=0x7fff58d2b9c8, mallocedp=0x7fff58d2b9bf, operate=0x3274f1b1c0 
> > <do_dlopen>, args=0x7fff58d2b9e0) at dl-error.c:178
> > #10 0x0000003274f1b29f in dlerror_run (address@hidden <do_dlopen>, 
> > address@hidden) at dl-libc.c:48
> > #11 0x0000003274f1b311 in __GI___libc_dlopen_mode (address@hidden 
> > "libgcc_s.so.1", address@hidden) at dl-libc.c:165
> > #12 0x0000003274ef7895 in init () at 
> > ../sysdeps/x86_64/../ia64/backtrace.c:53
> > #13 0x0000003274ef79e5 in __GI___backtrace (address@hidden, address@hidden) 
> > at ../sysdeps/x86_64/../ia64/backtrace.c:104
> > #14 0x0000003274e74364 in __libc_message (address@hidden, address@hidden 
> > "*** glibc detected *** %s: %s: 0x%s ***\n") at 
> > ../sysdeps/unix/sysv/linux/libc_fatal.c:178
> 
> ...in order to report malloc arena corruption...
> 
> > #15 0x0000003274e79d2e in malloc_printerr (action=3, str=0x3274f6248b 
> > "malloc(): memory corruption", ptr=<optimized out>) at malloc.c:5007
> > #16 0x0000003274e7b7e4 in _int_malloc (av=0x32751a1620 <main_arena>, 
> > bytes=<optimized out>) at malloc.c:3555
> > #17 0x0000003274e7ed90 in __libc_calloc (n=216713008672, address@hidden, 
> > elem_size=0, address@hidden) at malloc.c:3274
> 
> ...detected while the malloc lock is already held.  That explains the
> deadlock.  Sounds like a glibc bug worth fixing (if it isn't already) -
> if glibc is going to go the the effort of informing the user about
> memory corruption, it should not use malloc() in the attempt.

I think there's a bug report for this out there already.  I believe
the best way to fix this would be to make malloc use mmap if it finds
that the heap is corrupt and the program is exiting.  For a
workaround, you could export MALLOC_CHECK_ to 2 so that the program
only aborts and does not try to print a backtrace.

Siddhesh



reply via email to

[Prev in Thread] Current Thread [Next in Thread]