Description of problem: tar is killed by glibc's malloc check when running this command on the attached tarball. tar xfv kernel-changes.tar [warren@ibmlaptop tmp]$ tar xfv kernel-changes.tar malloc: using debugging hooks rpmbuild/SOURCES/linux-2.6.0-exec-shield.patch rpmbuild/SOURCES/linux-2.6.8-ppc64-netboot.patch *** glibc detected *** free(): invalid pointer: 0x08492000 *** Aborted It succeeds without visible errors if you disable the malloc check. [warren@ibmlaptop tmp]$ MALLOC_CHECK_=0 tar xfv kernel-changes.tar rpmbuild/SOURCES/linux-2.6.0-exec-shield.patch rpmbuild/SOURCES/linux-2.6.8-ppc64-netboot.patch This error means either: * double free() attempt * memory corruption (buffer overrun etc) * trying to free something not allocated by malloc, e.g. string literal or something like that When attempting to execute this in gdb, it fails to execute. Backtrace after interrupt is: #0 0x009f4782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00ac2293 in __read_nocancel () from /lib/tls/libc.so.6 #2 0x08065ed3 in ?? () #3 0x00000000 in ?? () Uncertain if this is related, but valgrind complains about a definite memory leak in tar. [warren@ibmlaptop tmp]$ MALLOC_CHECK_=3 valgrind --leak-check=yes --tool=memcheck tar xfv kernel-changes.tar malloc: using debugging hooks malloc: using debugging hooks ==13456== Memcheck, a memory error detector for x86-linux. ==13456== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. ==13456== Using valgrind-2.2.0, a program supervision framework for x86-linux. ==13456== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==13456== For more details, rerun with: -v ==13456== rpmbuild/SOURCES/linux-2.6.0-exec-shield.patch rpmbuild/SOURCES/linux-2.6.8-ppc64-netboot.patch ==13456== ==13456== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 14 from 1) ==13456== malloc/free: in use at exit: 63 bytes in 7 blocks. ==13456== malloc/free: 101 allocs, 94 frees, 17722 bytes allocated. ==13456== For counts of detected errors, rerun with: -v ==13456== searching for pointers to 7 not-freed blocks. ==13456== checked 1504596 bytes. ==13456== ==13456== 24 bytes in 1 blocks are definitely lost in loss record 1 of 2 ==13456== at 0x1B902A90: malloc (vg_replace_malloc.c:131) ==13456== by 0x8066240: (within /bin/tar) ==13456== by 0x805F3E9: (within /bin/tar) ==13456== by 0xA21AF2: __libc_start_main (in /lib/tls/libc-2.3.3.so) ==13456== ==13456== LEAK SUMMARY: ==13456== definitely lost: 24 bytes in 1 blocks. ==13456== possibly lost: 0 bytes in 0 blocks. ==13456== still reachable: 39 bytes in 6 blocks. ==13456== suppressed: 0 bytes in 0 blocks. ==13456== Reachable blocks (those to which a pointer was found) are not shown. ==13456== To see them, rerun with: --show-reachable=yes Version-Release number of selected component (if applicable): tar-1.14-2
Created attachment 104650 [details] kernel-changes.tar
Compiling with mtrace(); as the first instruction in main() will show this after a run: # mtrace tar aaa - 0x08206000 Free 64 was never alloc'd /usr/src/redhat/BUILD/tar-1.14/src/buffer.c:914 Memory not freed: ----------------- Address Size Caller 0x08205c20 0xc at 0x80669ba 0x08205c30 0x14 at 0x80669ba 0x08205c48 0x3 at 0x80669ba 0x08205c58 0x3 at 0x80669ba Important is only the first line, not the leaks. There seems to be a memory handling problem.
Turns out this one is a glibc problem. tar uses valloc (probably the only one doing so) and valloc didn't use the hooks (used for debugging with MALLOC_CHECK_ and for mtrace). After adding the hooks the program runs fine. Should be in the next glibc version (2.3.3-64). Note that this is no problem for the normal mode of operation. Only when MALLOC_CHECK_ is used with a nonzero value.
Fixed in rawhide.
Please see my updates for bug #132953, it should be this problem reappears.