Bug 134385 - tar free(): invalid pointer
Summary: tar free(): invalid pointer
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-10-01 21:16 UTC by Warren Togami
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version: 2.3.3-65
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-06 04:38:28 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
kernel-changes.tar (50.00 KB, application/octet-stream)
2004-10-01 21:17 UTC, Warren Togami
no flags Details

Description Warren Togami 2004-10-01 21:16:11 UTC
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
*** glibc detected *** free(): invalid pointer: 0x08492000 ***

It succeeds without visible errors if you disable the malloc check.

[warren@ibmlaptop tmp]$ MALLOC_CHECK_=0 tar xfv kernel-changes.tar

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
==13456== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==13456== For more details, rerun with: -v
==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== 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== 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):

Comment 1 Warren Togami 2004-10-01 21:17:12 UTC
Created attachment 104650 [details]

Comment 2 Ulrich Drepper 2004-10-01 22:39:22 UTC
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

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.

Comment 3 Ulrich Drepper 2004-10-01 23:50:37 UTC
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.

Comment 5 Ulrich Drepper 2004-10-06 04:38:28 UTC
Fixed in rawhide.

Comment 6 Vladimir Kondratiev 2005-02-12 15:39:55 UTC
Please see my updates for bug #132953, it should be this problem 

Note You need to log in before you can comment on or make changes to this bug.