SIGSEGV: exceptions with thread specific data

[Rimantas Plaipa]

At 09:16 1999.03.16 -0800, hjl@gnu.org wrote:
>The bug is in egcs. The problem is we share one data structure for
>EH frame info. When we have more than one thread, we will have
>trouble. When a thread throws an exception, it will modify the
>global EH frame info with the return from malloc, which is thread
>specific. Later on, another thread may cleanup the global EH frame
>info upon exit. It will call free on the memory malloced by the
>other thread. It won't work.
>
>I don't know what the best way to fix it is. We may do
>
>1. Free those EH frame info data within the thread which throwed the
>exception and malloced those memory right after they are used. Or
>2. Use global malloc/free for the global EH frame info. Or
>3. Use the thread specific EH frame info. Or
>4. Modify glibc to handle this special case.
>
>I prefer #1 if it can work. It may work with some modifications to
>frame.c and libgcc2.c. Also I don't know what will happen if 2 threads
>throw exceptions at the same time. 
>
>-- 
>H.J. Lu (hjl@gnu.org)
>


Could anybody from egcs confirm this ? I believed that this is fixed in
egcs-1.1.1 (didn't check earlier versions). Isn't this what the config
option --enable-threads=<lib> is for ? 

I think the the 'bug' in EGCS is that this option is documented very poorly:

configure.html:

--enable-threads -- Specify that the target supports threads. This only
effects the Objective-C compiler and runtime library. 
--enable-threads=lib -- Specify that lib is the thread support library.
This only effects the Objective-C compiler and runtime library. 

It doesn't specify what library and how will be affected.

I used exceptions and threads while programming for the certain platform
earlier and when I started programming for Linux I was very anxious if GCC
supports these things. That's why I've passed from GCC to EGCS. Of course I
knew that exception handling inevitably uses some global variables and
therefore needs special care in multithreaded applications. I consulted
source codes of libgcc2 of egcs-1.1.1 and found that indeed the tread-safe
exception handling is provided if certain compilation macros are defined
(using thread specific keys for EH frame - option #3 according H.J.Lu
classification ).
So I recompiled egcs with --enable-threads=posix. Well, I didn't test it
very well with threads so far but at least I checked with nm that EH
section of libgcc.a imports pthread_key_.. routines from pthread library.

I don't know also what effect has the bare option --enable-threads without
providing library. I don't know nothing about Objective-C but I'm certain
that it can't affect C++ runtime library ( and exception handling).

But even if compiler is made with thread-enabling options there are more
trouble.

libstdc++.so.2.9... which is build together with egcs includes all
exception routines (from libgcc.a). Therefore any executable linked with
libstdc++.so.2.9 imports exception support code dynamicaly from
libstdc++.so . This means that if the executable requires thread-safe
exceptions it should be run in computers with thread-enabled
libstdc++.so.2.9 installed. Of course I hope that some day I will be able
to present my programs for public so I'm  worrying if other people will be
able to run them. I checked libstdc++.so.2.9 in several main current Linux
distributions. Suse provides non-thread-safe library. I can't say nothing
about Debian because 'nm libstdc++.so' with the file from
libstdc-2.9.2.91.60-5.deb  results in message:

'no symbols found'.

Looks that somebody was obsessed with stripping.

So my final conclusion is that even if egcs is able to provide thread-safe
exceptions nobody knows or cares about that. Even the egcs staff.

(BTW , egcs info files omits -fno-rtti option. I had to search usenet
archives  to learn about it. Was this done intentionaly to force people to
recompile all old C++ libraries with egcs ?)


Rimantas Plaipa,

Department of Biochemistry and Biophysics,
Vilnius University,
Ciurlionio 21/27, Vilnius 2009, Lithuania.

E-mail: rp010gf@voruta.vu.lt
Phone: (370-2)-650381 
Fax: (370-2)-235049