Bug 14898 - Unable to create small static TLS block in shared library
Summary: Unable to create small static TLS block in shared library
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.15
: P2 normal
Target Milestone: 2.17
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2012-11-30 17:12 UTC by Bharath Ramesh
Modified: 2017-10-26 21:07 UTC (History)
4 users (show)

See Also:
Last reconfirmed:
fweimer: security-

tarball to reproduce bug (391 bytes, application/x-tar)
2012-11-30 17:12 UTC, Bharath Ramesh

Note You need to log in before you can comment on or make changes to this bug.
Description Bharath Ramesh 2012-11-30 17:12:00 UTC
Created attachment 6766 [details]
tarball to reproduce bug

If shared library declease a single TLS global variable of size 1 (one) byte, and this TLS variable is accessed by the binary linking against it the shared library doesnt get loaded because there is an error creating the static TLS block. The attached test case shows both the failed and expected behavior.

Untar the files from the tar ball. To reproduce the bug please compile the shared library as follows:

gcc -g -Wall -Wextra -fPIC -pthread -shared -DBUG -o libfoo.so  foo.c

gcc -g -Wall -Wextra -DBUG -o test test.c -Wl,-rpath . -L . -lfoo

$ ./test
./test: error while loading shared libraries: ./libfoo.so: cannot allocate memory in static TLS block

To get the expected behavior recompile the tests as follows

gcc -g -Wall -Wextra -fPIC -pthread -shared -o libfoo.so  foo.c

gcc -g -Wall -Wextra -o test test.c -Wl,-rpath . -L . -lfoo

$ ./test
foo: 1
address of foo: 0x7f3d359c56fe

The behavior is same if the library is compiled without -pthread. I have tested this bug in my system running Ubuntu precise using eglibc-2.15.
Comment 1 Andreas Schwab 2012-11-30 20:21:30 UTC
a45bd0d9682db986191b075e64bcacd038af5993 probably fixes that.
Comment 2 Maxim Kuvyrkov 2012-12-04 02:39:41 UTC
This appears to be fixed in current mainline (tested on mips64-linux-gnu).  Moving milestone to 2.15.1.
Comment 3 Maxim Kuvyrkov 2012-12-04 02:46:50 UTC

Your commit a45bd0d9682db986191b075e64bcacd038af5993 is only on the Fedora branch, yet I can't reproduce the problem with current sources.  Was the bug fixed on trunk by a different patch?
Comment 4 Bharath Ramesh 2012-12-04 03:45:09 UTC
I can reproduce this on a Centos 6.3 with glibc-2.12. I am trying to see if I can get access to a FC17 workstation.
Comment 5 Andreas Schwab 2012-12-04 09:22:23 UTC
(In reply to comment #3)
> yet I can't reproduce the problem with current sources.

I don't know what you tested, but the error is still present on master, and the commit still fixes it.
Comment 6 Bharath Ramesh 2012-12-04 22:48:33 UTC
I tested this in a newer version of ubuntu running eglibc-2.16 and the error still exists. I will see if I can get access FC17 with glibc-2.15.
Comment 7 Maxim Kuvyrkov 2012-12-05 06:24:13 UTC

Was your patch posted to libc-alpha@?
Comment 8 Bharath Ramesh 2012-12-05 21:39:44 UTC
FC17 with glibc-2.15 doesnt have this issue.
Comment 9 law 2012-12-05 22:48:59 UTC
Bharath, that's because Fedora has included the patch posted by Andreas.
Comment 10 Andreas Schwab 2013-01-14 14:12:38 UTC
Fixed in 2.17.
Comment 11 Carlos O'Donell 2017-10-26 21:07:38 UTC
(In reply to Andreas Schwab from comment #10)
> Fixed in 2.17.

Just for reference, the fix was to adjust the internal constant not to be the same value as a small sized static TLS image. A workaround is always to increase the size of the TLS storage.

commit 67cbf9a2a9e8953aa7ea875938d6646727c71aaa
Author: Andreas Schwab <schwab@linux-m68k.org>
Date:   Fri Dec 7 14:55:19 2012 -0700

            [BZ #14898]
            * include/link.h (FORCED_DYNAMIC_TLS_OFFSET) [NO_TLS_OFFSET == 0]:
            Change to -1.