public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug malloc/17730] New: thread-local storage is sometimes improperly free()'d after being __libc_memalign()'d
@ 2014-12-19 3:03 bradley at mit dot edu
2014-12-22 10:13 ` [Bug malloc/17730] " fweimer at redhat dot com
2014-12-22 13:22 ` bradley at mit dot edu
0 siblings, 2 replies; 3+ messages in thread
From: bradley at mit dot edu @ 2014-12-19 3:03 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-12-22 13:22 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-19 3:03 [Bug malloc/17730] New: thread-local storage is sometimes improperly free()'d after being __libc_memalign()'d bradley at mit dot edu
2014-12-22 10:13 ` [Bug malloc/17730] " fweimer at redhat dot com
2014-12-22 13:22 ` bradley at mit dot edu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).