This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug malloc/16573] New: mtrace hangs when MALLOC_TRACE is defined
- From: "kcy at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 13 Feb 2014 11:39:57 +0000
- Subject: [Bug malloc/16573] New: mtrace hangs when MALLOC_TRACE is defined
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=16573
Bug ID: 16573
Summary: mtrace hangs when MALLOC_TRACE is defined
Product: glibc
Version: 2.19
Status: NEW
Severity: minor
Priority: P2
Component: malloc
Assignee: unassigned at sourceware dot org
Reporter: kcy at codesourcery dot com
Created attachment 7409
--> https://sourceware.org/bugzilla/attachment.cgi?id=7409&action=edit
Mtrace test program
On any current Linux distribution with glibc, if mtrace_test.c is compiled and
executed as follows, it displays:
$ MALLOC_TRACE="mtrace.log" ./mtrace_test
*** Error in `./mtrace_test': double free or corruption (fasttop):
0x0000000000efc460 ***
before hanging indefinitely. Checking the backtrace with GDB:
#0 __lll_lock_wait_private ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1 0x00007ffff7a99915 in _L_lock_45 () at mtrace.c:379
#2 0x00007ffff7a99088 in lock_and_info (
caller=caller@entry=0x7ffff7de2c37 <_dl_map_object+1159>,
mem=mem@entry=0x7fffffffd770) at mtrace.c:128
#3 0x00007ffff7a9931e in tr_mallochook (size=36,
caller=0x7ffff7de2c37 <_dl_map_object+1159>) at mtrace.c:172
#4 0x00007ffff7de2c37 in local_strdup (
s=0x7ffff7fe6883 "/lib/x86_64-linux-gnu/libgcc_s.so.1") at dl-load.c:162
#5 _dl_map_object (loader=loader@entry=0x7ffff7ff94c0,
name=name@entry=0x7ffff7b94b26 "libgcc_s.so.1", type=type@entry=2,
trace_mode=trace_mode@entry=0, mode=mode@entry=-1879048191,
nsid=<optimised out>) at dl-load.c:2510
#6 0x00007ffff7dedd54 in dl_open_worker (a=a@entry=0x7fffffffddb8)
at dl-open.c:239
#7 0x00007ffff7de96e6 in _dl_catch_error (
objname=objname@entry=0x7fffffffdda8,
errstring=errstring@entry=0x7fffffffddb0,
mallocedp=mallocedp@entry=0x7fffffffdda0,
operate=operate@entry=0x7ffff7dedc00 <dl_open_worker>,
args=args@entry=0x7fffffffddb8) at dl-error.c:177
#8 0x00007ffff7ded809 in _dl_open (file=0x7ffff7b94b26 "libgcc_s.so.1",
mode=-2147483647, caller_dlopen=<optimised out>, nsid=-2, argc=1,
argv=0x7fffffffeb38, env=0x7fffffffeb48) at dl-open.c:667
#9 0x00007ffff7b49da2 in do_dlopen (ptr=ptr@entry=0x7fffffffdfc0)
at dl-libc.c:87
#10 0x00007ffff7de96e6 in _dl_catch_error (objname=0x7fffffffdfa0,
errstring=0x7fffffffdfb0, mallocedp=0x7fffffffdf90,
operate=0x7ffff7b49d60 <do_dlopen>, args=0x7fffffffdfc0) at dl-error.c:177
#11 0x00007ffff7b49e62 in dlerror_run (args=0x7fffffffdfc0,
operate=0x7ffff7b49d60 <do_dlopen>) at dl-libc.c:46
#12 __GI___libc_dlopen_mode (name=name@entry=0x7ffff7b94b26 "libgcc_s.so.1",
mode=mode@entry=-2147483647) at dl-libc.c:163
#13 0x00007ffff7b242d9 in init () at ../sysdeps/x86_64/backtrace.c:52
#14 __GI___backtrace (array=array@entry=0x7fffffffe250, size=size@entry=64)
at ../sysdeps/x86_64/backtrace.c:103
#15 0x00007ffff7a86515 in __libc_message (do_abort=do_abort@entry=2,
fmt=fmt@entry=0x7ffff7b9a240 "*** Error in `%s': %s: 0x%s ***\n")
at ../sysdeps/unix/sysv/linux/libc_fatal.c:178
#16 0x00007ffff7a92996 in malloc_printerr (ptr=0x602460,
str=0x7ffff7b9a408 "double free or corruption (fasttop)", action=3)
at malloc.c:4923
#17 _int_free (av=<optimised out>, p=0x602450, have_lock=0) at malloc.c:3779
#18 0x00007ffff7a996b8 in tr_freehook (caller=0x400640 <main+51>, ptr=0x602460)
at mtrace.c:158
#19 tr_freehook (ptr=0x602460, caller=0x400640 <main+51>) at mtrace.c:136
#20 0x0000000000400640 in main ()
The problem is that although tr_freehook replaces __free_hook with the old hook
before calling free or the old hook, the malloc hook is still pointing to
tr_mallochook. Further down the call chain, a malloc is performed, resulting in
tr_mallochook being called. It tries to acquire the lock, which is still held
by tr_freehook, resulting in a deadlock.
--
You are receiving this mail because:
You are on the CC list for the bug.