[Bug libc/221] New: C++ throw terminates ucontext_t context, instead of returning via uc_link

[Bug libc/221] New: C++ throw terminates ucontext_t context, instead of returning via uc_link

[a dot darovskikh at compassplus dot ru]

When an exception occurs in another execution thread 
created with makecontext(), it causes program to exit 
with SIGABRT, instead of being catched in the main thread. 
 
Returning from this function works OK. I use recent GCC (3.4.0), 
and, as far as I understand, the problem is somewhere inside 
_Unwind_RaiseException, which doesn't check if it's another context. 
 
The test case is included.

-- 
           Summary: C++ throw terminates ucontext_t context, instead of
                    returning via uc_link
           Product: glibc
           Version: 2.3.3
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: gotom at debian dot or dot jp
        ReportedBy: a dot darovskikh at compassplus dot ru
                CC: glibc-bugs at sources dot redhat dot com
  GCC host triplet: i686-pc-linux-gnu


http://sources.redhat.com/bugzilla/show_bug.cgi?id=221

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/221] C++ throw terminates ucontext_t context, instead of returning via uc_link

[a dot darovskikh at compassplus dot ru]

------- Additional Comments From a dot darovskikh at compassplus dot ru  2004-06-16 09:54 -------
Created an attachment (id=116)
 --> (http://sources.redhat.com/bugzilla/attachment.cgi?id=116&action=view)
A test case for exception throwing


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=221

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/221] C++ throw terminates ucontext_t context, instead of returning via uc_link

[a dot darovskikh at compassplus dot ru]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |a dot darovskikh at
                   |                            |compassplus dot ru


http://sources.redhat.com/bugzilla/show_bug.cgi?id=221

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/221] C++ throw terminates ucontext_t context, instead of returning via uc_link

[jakub at redhat dot com]

------- Additional Comments From jakub at redhat dot com  2004-06-18 11:18 -------
I don't think anything like this is required by any standards.
For each target, one would have to describe the makecontext helper behaviour
in terms of DWARF2/3 unwind info.  Say on i386, the helper increases stack
pointer by 4 * %ebx (easy), reads link pointer from the stack, then needs
conditionally go to an area without unwind info (exit case) or simulate the
effect of setcontext call.

-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=221

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/221] C++ throw terminates ucontext_t context, instead of returning via uc_link

[a dot darovskikh at compassplus dot ru]

------- Additional Comments From a dot darovskikh at compassplus dot ru  2004-06-18 11:32 -------
Subject: Re:  C++ throw terminates ucontext_t context, instead of returning via uc_link

On Friday 18 June 2004 17:18, jakub at redhat dot com wrote:
> ------- Additional Comments From jakub at redhat dot com  2004-06-18 11:18
> ------- I don't think anything like this is required by any standards.

Maybe it's not required, literally, but in the terms of a common sense,
this is nice to be implemented. In Windows (CreateFiber, SwitchToFiber, ...)
this works nicely. If there's an exit it is used.

I don't understand, why return works as expected, but exception does not.
uc_link is designed for this purpose, isn't it? Maybe exceptions aren't listed 
in standards because ucontext is thought as a C API?

Then there should be some kind of documented workaround, isn't it?


-- 


http://sources.redhat.com/bugzilla/show_bug.cgi?id=221

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/221] C++ throw terminates ucontext_t context, instead of returning via uc_link

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2004-08-10 02:26 -------
User contexts are no threads.  And they won't behave like this.  If you don't
catch an exception in one context the whole process dies.  That's the correct
behavior.

Not even threads have today the functionality of selecting whether only one
thread gets terminated in case of an uncaught exception, or as usual the whole
process.  There are talks about adding this extension and this actually might
make sense.  

For contexts all this is so underspecified that adding this functionality leads
to more problems.  Like, throw and exceptions from a signal handler; if the
currently used context is not prepared this will kill it even though the event
has nothing to do with the context.  And what would it mean if the currently
used context is replaced with the one addressed by uc_link?  The old context is
not really destroyed.  It can always be restarted.  The whole point behind user
contexts is that they under complete control of the user code.  The user code
must control the lifespan of the contexts.  The runtime cannot meddle with it.

And it is very simple for the user to implement something adequately: just
install the correct catch blocks in the initial function registered with
makecontext.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


http://sources.redhat.com/bugzilla/show_bug.cgi?id=221

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.