Re: Frame-based exception handling problem on Server 2008

Adrian Tulloch wrote:
"Corinna Vinschen" <corinna@xxxxxxxxxxxxxxxx> wrote in message
news:fq3e9o$u3d$2@xxxxxxxxxxxxxxxxxx
The simple case is that the application has no signal handler installed.
In this case, the exception ends fatal, usually Cygwin creates a stack
dump. In this case all other exception handlers should get a chance to
cleanup, so unwinding is correct.

Can't you return ExceptionContinueSearch without doing any unwinding here?
That way the OS will call into the next handler on the chain, giving it a
chance to handle the problem. If anything, I'd have thought that unwinding
may cause problems here.

But that's exactly what we don't want. The Cygwin DLL is a POSIX
emulation layer in Win32 user space trying to be as Linux-compatible on
the API level and in general behaviour as possible. Our exception
handler is supposed to be *the* (final) exception handler for Cygwin
applications.

The next handler in the chain is the OS handler which just terminates
the application and shows the "application has terminated unexpectedly"
GUI. All other potential handlers are higher in the chain.

Usually there are no other handlers, but if so, the fact that our
exception handler got called shows that these exception handlers don't
know how to handle this exception anyway. Otherwise they wouldn't
have returned ExceptionContinueSearch.

What if the application has a signal handler installed? Cygwin's
exception handler does not know if that signal handler will take the
right measures to rectify the problem which led to the exception or not.
It also does not know if the signal handler returns or not. So, for
all it knows, the signal handler will handle the exception, one way
or the other. So unwinding is the right thing to do to say the other
exception handlers, "we care".

In another message in this thread, you mentioned that you've got a couple of
patches which fix this problem. Can you point me to them? I feel that we may
be talking at cross purposes here, and seeing those patches may help fix
that.

The final solution we agreed on is not to return from the exception
handler after unwinding, but to return to the point of the exception
immediately:

http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/exceptions.cc.diff?cvsroot=uberbaum&r1=1.311&r2=1.312

I'd have thought that, if the signal handler does fix the problem and
returns, returning ExceptionContinueExecution and *not* unwinding makes
everything work, and is doing "the right thing" by the OS. In the situation

As I explained, the exception handler doesn't know what the signal
handler will do. It's in the application which is just "some"
application we don't know anything about.

where the signal handler doesn't return (is a longjmp the only way this
occurs?), the long jumper is responsible for changing the program state to
into a form that's appropriate for the target of the jump. This manipulation
of the program state may or may not involve doing a RtlUnwind, but that's
the decision of the long jumper, not the generic exception handler.

The signal handler has no access to the exception information given
to the exception handler. It gets only the signal number as parameter.
longjmp just reverts the state of the CPU as stored in the jmp_buf by
the call to setjmp. When setjmp is called there's no information about
any exception available.


Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
.

Relevant Pages

  • Re: Try Finally...
    ... Now we can protect every more or less specialized action ... an error indication (exception or error code) has to be ... an according exception handler can be inserted into the code. ... resources, as they are related to specific actions. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Frame-based exception handling problem on Server 2008
    ... so the exception table stuff must only be in the retail visual ...   jmp_buf j; ... The signal handler in the application code is called by Cygwin's ... SIGSEGV but SIGFPE, so it has no signal handler installed, thus Cygwin's ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Frame-based exception handling problem on Server 2008
    ... In this case, the exception ends fatal, usually Cygwin creates a stack ... handler is supposed to be *the* exception handler for Cygwin ... The next handler in the chain is the OS handler which just terminates ...
    (microsoft.public.win32.programmer.kernel)
  • Re: WinForms bug? ThreadException not invoked on Exceptions in system code pre-processing the me
    ... Message Queue and invoking the appropriate handler. ... if an Exception is raised during the PRE-PROCESSING of a Windows ... And because any handling will probably fail if there is no memory, the CLR will terminate the application without attempting to call the ApplicationException or UnhandledException events. ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: BackgroungWork taske ended for no appearent reason
    ... To do the same thing with Try/Catch blocks requires wrapping every file access with a Do While ... ... If there was any exception thrown in your DoWork event handler, ... If the operation raises an exception that your code does not handle, ... Microsoft Online Community Support ...
    (microsoft.public.dotnet.languages.vb)
Loading