AW: [omniORB] NameService crashes - Sock

Liutger Franzen ilfranze@TechFak.Uni-Bielefeld.DE
Thu, 24 Sep 1998 11:24:44 +0200


> It's quite amazing. Dou you really mean any exception you throw leads to
> a core dump? I've tested your proposal, but I'm not able to confirm the
> bahaviour.

I guess I found the reason of this core-dumping w/ threads using
exceptions. At least if the mechanism is the same like with
SGI-Compiler:

There is a function which is used by the exceptionhandler to determine
the thread, which had thrown the exception. Here is is comment from
exceptions.h from SGI MIPS Pro 7.2:

>   /* The exception handling runtime needs to know the identity of the thread
>      doing a throw, so that it can process the exception on behalf of that
>      thread.  By default, the exception handling will assume the pid of
>      the process as the thread identity. If the thread model used in the 
>      program allow for more than one thread of execution per process, 
>      set_thread_id_function should be set to point to a function that returns 
>      the thread id.  The exception handling runtime will call this function 
>      when the user program does a throw, to get the id of thread. */
>   typedef long (*_PFL)();
>   /* set_thread_id_function() sets the thread id function and returns the 
>      previous thread identity function. */
>   extern _PFL set_thread_id_function(_PFL);

If this function is not set, the exceptionhandler allways assumes, the
exception throwing thread is the main thread. If it it not, the
exceptionhandler in that thread cannot catch the exception and calls
abort() and terminate(). At least this seems to be the way it works (or
does not work ;-) ) with SGI. In newer versions of the pthread-library,
this function is correctly set to a function that actually reports the
correct thread, I am just about to verify this using the appropriate
thread ... Anybody with similar experiences?

Lio

--
Butthead: 'Beavis - Just shut up and like free your mind or something.'