This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Hanging conftest


On Thu, Nov 28, 2013 at 10:30:20AM +0530, Siddhesh Poyarekar wrote:
> 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 (loader=loader@entry=0x7feab7c5c658, name=name@entry=0x3274f60e30 "libgcc_s.so.1", type=type@entry=2, trace_mode=trace_mode@entry=0, mode=mode@entry=-1879048191, nsid=<optimized out>)
> > >     at dl-load.c:2249
> > > #5  0x0000003274a12a2c in dl_open_worker (a=a@entry=0x7fff58d2b7c0) at dl-open.c:225
> > > #6  0x0000003274a0e8c4 in _dl_catch_error (objname=objname@entry=0x7fff58d2b7b0, errstring=errstring@entry=0x7fff58d2b7b8, mallocedp=mallocedp@entry=0x7fff58d2b7af, operate=operate@entry=0x3274a12900 <dl_open_worker>, 
> > >     args=args@entry=0x7fff58d2b7c0) 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 (ptr=ptr@entry=0x7fff58d2b9e0) 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 (operate=operate@entry=0x3274f1b1c0 <do_dlopen>, args=args@entry=0x7fff58d2b9e0) at dl-libc.c:48
> > > #11 0x0000003274f1b311 in __GI___libc_dlopen_mode (name=name@entry=0x3274f60e30 "libgcc_s.so.1", mode=mode@entry=-2147483647) at dl-libc.c:165
> > > #12 0x0000003274ef7895 in init () at ../sysdeps/x86_64/../ia64/backtrace.c:53
> > > #13 0x0000003274ef79e5 in __GI___backtrace (array=array@entry=0x7fff58d2bc80, size=size@entry=64) at ../sysdeps/x86_64/../ia64/backtrace.c:104
> > > #14 0x0000003274e74364 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x3274f65470 "*** 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, n@entry=88, elem_size=0, elem_size@entry=1) 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.
>
Its this bug
https://sourceware.org/bugzilla/show_bug.cgi?id=16159 

a switch to mmap should be made in wider set as this also applies to
signal handlers and lazy tls initialization. It will make malloc bit
slower so we should decide if it is worth cost.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]