[omniORB] problem using gdb

[Helmut Swaczinna]

Sai-Lai,

At , you wrote:
>To be fair with egcs, it has come a long way in the support of MT C++
>applications. Having said that, I do see occasional SEGV on Redhat 5.2
>(glibc-2.0) with egcs. This happens with Code Fusion as well. Trouble is
>there is no core dump to examine so I haven't got a clue what has gone
>wrong. On occasions I see the SEGV under gdb, it is always inside the
>iostream library and happens when two threads are writing at the same
>time. This makes me wonder if the iostream library is not designed to allow
>concurrent write to the same output stream (cerr).

I've found some messages in the libstdc++ mailing-archive, which declared the
iostreams explicitly as *not* thread safe. But may be it was fixed in the
meantime. The stdlibc++ is *not* thread safe. This statement can be found
on the current bugs-list. 

>It doesn't help when egcs might be built without --enable-threads. Although
>egcs installation notes tells you that --enable-threads is only applicable
>to Objective C, I'm certain that you must use this flag to build or else
>you got MT exception handling problem. Can we be sure all the linux
>distributions built their egcs compiler with the flag? I'm not sure and
>tend to believe that some don't (SuSe for example).

Yes, in SuSE <= 6.1 --enable-threads is *not* set.

>With a debugger that works with MT applications, it should be easier to
>find out where the bug is. If linux has a working core dump for MT
>programs, it will be even better.

I've ported my progs to Solaris in the meantime. The gdb on Solaris works
very nice with threads. (But there are other problems on Solaris.)

>I don't think you need to worry too much about reliably. So far the problem
>I have is confined to concurrent writes to iostream cerr. 

So if I turn off the trace messages, this problem shouldn't appear anymore,
I think. (I'm not using iostreams.)


Helmut