[Mingw-notify] [ mingw-Bugs-2837096 ] [gcc 4.4.0] Exception handling not thread-safe

[SourceForge.net <no...@so...>]

Bugs item #2837096, was opened at 2009-08-13 15:53
Message generated for change (Settings changed) made by peterjhurley
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837096&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: gcc
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Peter Hurley (peterjhurley)
Assigned to: Nobody/Anonymous (nobody)
Summary: [gcc 4.4.0] Exception handling not thread-safe

Initial Comment:
Due to defect# #2837047 ([gcc-4.4.0] __thread not producing thread-specific storage), exception handling is not currently thread-safe.

Compiling and running the attached source submission file, terminates from multiple locations within the exception framework due to internally corrupted data structures. Compiles and runs successfully when single-threaded.

-- Discussion --
The test jig creates the number of threads specified by the 'processors' variable.  The original process thread then waits for the spawned threads to terminate.  The thread_fn executed by each thread (other than the original process thread), loops a number of times, and within each loop, generates an exception which it intends to catch.

The exception is actually thrown from nested_fn.  The thrown exception is an unsigned long containing the thread id of the throwing thread as an additional verification.  To increase the chances that multiple threads will be throwing and unwinding at the same time, a local object is created in the try block with a destructor that sleeps the thread.

When 'processors' is set to 1, only one thread is created and the test completes successfully, having caught 1000 exceptions in 1000 loops.  When 'processors' is set to > 1, the test jig terminates (sometimes through _verbose_terminate_handler in vterminate.cc).

-- Details --
The c++ implementation of exception handling in libsupc++ uses a thread-specific pointer to maintain a list of active exceptions - that is, exceptions currently being processed by catch (in between __cxa_begin_catch/__cxa_end_catch) - and a count of exceptions that have been thrown but not yet caught.

This thread-specific pointer is obtained by a call to __cxa_get_globals()  (in libsupc++\eh_globals.cc) , which in turn calls get_global().  The static __thread variable 'global' is *not* currently being generated as a thread-specific value.  Since __thread is currently broken (see reference to defect at the top of this report), this is mapping to a call to _emutls_get_address which is *not* unique per-thread.

The chain of exceptions quickly becomes corrupted to the point where the exception handling code believes its managing foreign frames and terminates.

[Build environment]
WinXP Pro SP3
intel harpertown
gcc-4.4.0-mingw
w32api-3.13
mingwrt-3.15.2
binutils-2.19.1

build command:
g++ -shared-libgcc -o smp_eh.o smp_eh.cpp

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837096&group_id=2435