This is the mail archive of the glibc-bugs@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]

[Bug malloc/17730] New: thread-local storage is sometimes improperly free()'d after being __libc_memalign()'d


https://sourceware.org/bugzilla/show_bug.cgi?id=17730

            Bug ID: 17730
           Summary: thread-local storage is sometimes improperly free()'d
                    after being __libc_memalign()'d
           Product: glibc
           Version: 2.18
            Status: NEW
          Severity: normal
          Priority: P2
         Component: malloc
          Assignee: unassigned at sourceware dot org
          Reporter: bradley at mit dot edu

Created attachment 8020
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8020&action=edit
test case

Sometimes libc obtains a block of memory using __libc_memalign(), and then
later deallocates the block using free().  

Since malloc/free may be redefined to be unrelated to the libc internal
malloc/free code, this is incorrect.  (malloc/free might be redefined in the
user code directly, or it might be installed using LD_PRELOAD or it might be
that another implementation of malloc is linked dynamically or statically into
the application).

Here are the conditions under which I can reproduce this problem:
 * The main user code defines its own malloc/free
 * The main user code dynamically loads a library using dlopen()/dlsym().
 * The library contains thread-local storage.
 * A thread runs, and then proceeds to touch the thread-local storage,
eventually invoking tls_get_addr_tail() (in /elf/dl-tls.c) and then
allocate_and_init() and then __libc_memalign().
 * Eventually, this storage is deallocated using free() instead __libc_free().

I ran this on Fedora 20, but it looks like the problem is still there on the
head of the git master of glibc.

Attached is a test case.  This test case implements its own very simple
malloc/free library and free complains if it is given a pointer which didn't
come from the library. It runs as follows. Observe the abort at the end.

[bradley@30-87-232 test]$ tar xfz libc-bug.tar.gz 
[bradley@30-87-232 test]$ cd libc-bug/
[bradley@30-87-232 libc-bug]$ make check
gcc -g -W -Wall -Werror -pthread -fPIC --shared libtls.c -o libtls.so
cc -g -W -Wall -Werror -pthread -fPIC    tls.c  -ldl -o tls
./tls
malloc(32)=0x6020c0
malloc(46)=0x6020e0
malloc(1214)=0x60210e
malloc(46)=0x6025cc
malloc(56)=0x6025fa
malloc(96)=0x602632
malloc(288)=0x602692
malloc(288)=0x6027b2
malloc(288)=0x6028d2
malloc(288)=0x6029f2
1048576
1048576
1048576
malloc(288)=0x602b12
1048576
1048576
free passed 0xea1010 not in range
make: *** [check] Aborted (core dumped)
[bradley@30-87-232 libc-bug]$

-- 
You are receiving this mail because:
You are on the CC list for the bug.


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