This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug malloc/17730] New: thread-local storage is sometimes improperly free()'d after being __libc_memalign()'d
- From: "bradley at mit dot edu" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 19 Dec 2014 03:02:39 +0000
- Subject: [Bug malloc/17730] New: thread-local storage is sometimes improperly free()'d after being __libc_memalign()'d
- Auto-submitted: auto-generated
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.