This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC 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 c/54129] New: __thread variables and pthread_*specific data destroyed in different order on Darwin than Linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54129

             Bug #: 54129
           Summary: __thread variables and pthread_*specific data
                    destroyed in different order on Darwin than Linux
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: blucia@gmail.com


Created attachment 27899
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27899
A test program that shows the behavior.

I have written a short program that works on Linux but does not work on Mac
OSX.  The program uses __thread variables, which I understand are emulated on
Darwin.  The program also uses pthread_key_create(..., thread_destructor) to
register the function thread_destructor() to run when threads end.  I have
attached a test program that works on Linux and does not work on OS X.

thread_destructor() accesses the __thread variables.  It looks like what is
happening is the __thread variables are being zeroed before thread_destructor()
is running.  Some of those __thread variables are pointers, leading to
segfaults when thread_destructor dereferences them.  

This may not be a bug.  I have not read the relevant parts of the language
specification.  It may be undefined to mix pthread_setspecific and __thread.  I
may be using some library functions wrong. However, it is definitely the case
that the behavior on Darwin is different from the behavior on Linux.

Note that this simple program is not the only place I've seen this.  I am
building a debugging/monitoring runtime system that makes heavy use of these
facilities and it first experienced the problem.  The attached program is
(pretty much) minimal to manifest the problem.


Program compiled with:
gcc -std=c99 ./TLSBug.c -o TLSBug

Output of test program on Mac OS X 10.6:
redoldfence:MacTLSBugTest blucia0a$ ./TLSBug 
Thread says foo == 0x100200130
Thread says *foo == 17
0123456789
Thread Destructor Called
Thread says foo == 0x0
Segmentation fault


Output of test program on Linux:
blucia@pango:~$ ./TLSBug 
Thread says foo == 0x2564160
Thread says *foo == 17
0123456789
Thread Destructor Called
Thread says foo == 0x2564160
Thread says *foo == 17


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