Bug 6547 - mcheck / mcheck_pedantic fails with multiple threads
Summary: mcheck / mcheck_pedantic fails with multiple threads
Status: RESOLVED WONTFIX
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-22 11:27 UTC by Suzuki
Modified: 2014-07-03 11:29 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments
Test case to reproduce the problem (628 bytes, text/plain)
2008-05-22 11:28 UTC, Suzuki
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Suzuki 2008-05-22 11:27:19 UTC
mcheck / mcheck_pedantic when used in a multi threaded program causes abort().

I will attach the testcase later.

[suzie@suzukikp bugs]$ cc mcheck_pedantic.c -lpthread
[suzie@suzukikp bugs]$ ./a.out 
mcheck 0
thread 1 started
created thread 0
thread 2 started
*** glibc detected *** ./a.out: munmap_chunk(): invalid pointer: 0xb7d00528 ***
======= Backtrace: =========
/lib/libc.so.6[0x4d0f7e4]
./a.out[0x80487fd]
/lib/libpthread.so.0[0xd5432f]
/lib/libc.so.6(clone+0x5e)[0x4d8027e]
======= Memory map: ========
00110000-00111000 r-xp 00110000 00:00 0          [vdso]
00205000-00221000 r-xp 00000000 08:03 254843     /lib/ld-2.8.so
00221000-00222000 r--p 0001c000 08:03 254843     /lib/ld-2.8.so
00222000-00223000 rw-p 0001d000 08:03 254843     /lib/ld-2.8.so
00d4e000-00d63000 r-xp 00000000 08:03 254845     /lib/libpthread-2.8.so
00d63000-00d64000 r--p 00014000 08:03 254845     /lib/libpthread-2.8.so
00d64000-00d65000 rw-p 00015000 08:03 254845     /lib/libpthread-2.8.so
00d65000-00d67000 rw-p 00d65000 00:00 0 
04ca2000-04e05000 r-xp 00000000 08:03 254844     /lib/libc-2.8.so
04e05000-04e07000 r--p 00163000 08:03 254844     /lib/libc-2.8.so
04e07000-04e08000 rw-p 00165000 08:03 254844     /lib/libc-2.8.so
04e08000-04e0b000 rw-p 04e08000 00:00 0 
05792000-0579f000 r-xp 00000000 08:03 254860     /lib/libgcc_s-4.3.0-20080428.so.1
0579f000-057a0000 rw-p 0000c000 08:03 254860     /lib/libgcc_s-4.3.0-20080428.so.1
08048000-08049000 r-xp 00000000 08:06 292709     /home/suzie/bugs/a.out
08049000-0804a000 rw-p 00000000 08:06 292709     /home/suzie/bugs/a.out
0804a000-0804e000 rw-p 0804a000 00:00 0 
08664000-08685000 rw-p 08664000 00:00 0          [heap]
b7d00000-b7d21000 rw-p b7d00000 00:00 0 
b7d21000-b7e00000 ---p b7d21000 00:00 0 
b7e8b000-b7e8c000 ---p b7e8b000 00:00 0 
b7e8c000-b7ecc000 rw-p b7e8c000 00:00 0 
b7ecc000-b7ecd000 ---p b7ecc000 00:00 0 
b7ecd000-b7f0f000 rw-p b7ecd000 00:00 0 
b7f25000-b7f26000 rw-p b7f25000 00:00 0 
bfe10000-bfe25000 rw-p bffeb000 00:00 0          [stack]
Aborted

This happens because there is no synchronization between the threads while
updating the __*_hook_ . This causes some threads to escape the mcheck overhead
and allocate memory block without an mcheck header. Freeing this are will endup
in abort().

Another path is a block allocated with the mcheck header may directly end up in
libc_free(), making libc confused about the chunk_ptrs.
Comment 1 Suzuki 2008-05-22 11:28:47 UTC
Created attachment 2755 [details]
Test case to reproduce the problem
Comment 2 Ulrich Drepper 2008-05-22 14:15:28 UTC
mcheck doe snot work for multi-threaded code.  It cannot possibly do.  There is
no way to fix this with the technology underlying mcheck.