GCJ/minGW produced executables and linux/wine

Wed Mar 5 09:19:00 GMT 2003

> > Well honestly, I don't know and I'm surprised that it works
> > on Linux (so signal delivery must be the "last mile" in that
> > the OS doesn't really care if the handler returns or not).
>> The ANS C standard says that signal handlers may return by doing a
> longjmp. But that's what I meant whan I said this is not a signal
> handler and may have other restrictions. And it seems like it does
> indeed have some restrictions.

I found a GCJ document relevant to this discussion at:
 http://gcc.gnu.org/java/port-signals.html
(I had seen it before, but hadn't understood its signficance till now. ;-))
> > I can imagine that there would be problems on Win32 because
> > this handler is supposed to return a value to the OS telling
> > it whether to execute the default handler (abort program)
> > or whether the exception has been handled successfully.

My conjecture seems correct as this simple program hangs on Win32
after printing "Strike 1!", instead of printing "Strike 2!" as well:
------------------------------- 8< --------------------------------
public class Snafu {
 public static void main( String[] args) {
 Object p = null;
 try {
 System.out.println( p.toString( ));
 } catch( NullPointerException e) {
 System.err.println( "Strike 1!");
 }
 try {
 System.out.println( p.toString( ));
 } catch( NullPointerException e) {
 System.err.println( "Strike 2!");
 }
 }
}
------------------------------- 8< --------------------------------
I guess instead of blindly throwing NullPointerException from within
win32_exception_handler( ) in win32.cc, we will have to modify
the return address a la MAKE_THROW_FRAME in posix.cc, and return
EXCEPTION_CONTINUE_EXECUTION as explicitly allowed by Windows:
http://msdn.microsoft.com/library/en-us/debug/base/setunhandledexceptionfilter.asp
Ranjit.