This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question about POSIX libgcj signals / exception handling


Hi David,

>> Are the signal handlers in POSIX libgcj set up
>> such that the application is bulletproof and
>> immune from core dumps?
>
>Certainly.  With java and especially libgcj it is impossible to write 
>buggy code.  I have not had a single bug in over three years!

:) This was meant to be read as "bulletproof from core
dumps and immune from core dumps" - i.e. anything that would
normally cause a core dump is properly converted to a Java
exception.

>That is a little out of date.  i386 MAKE_THROW_FRAME is a nop.  Stack 
>unwinding through the signal frame is handled by the DWARF based 
>exception unwinder in libgcc.

Thanks. Hadn't realized this.

>SIGSEGV gets converted to NullPointerException.  This is unconditional 
>it happens even if the faulting location is far away from address zero. 
>      Native code is not treated any differently than the java code. 
>Any SIGSEGV is converted to NPE.

>SIGFPE likewise is converted to ArithmaticException, but on the x86 some 
>analysis of the faulting code is done first as x86 sometimes generates 
>the SIGFPE when the JLS requires it not to throw the exception.  In this 
>case things are fixed up and control returned to the faulting code.

>The GC uses two signals that are not related to machine faults.  The 
>Thread.Interrupt facility also uses a signal (I forget which ones), 
>java.lang.Process uses SIGCHLD.

>SIGBUS and SIGILL are not handled by libgcj.  If you get one of them, 
>your program will be terminated unless you explicitly install your own 
>handler for them.  But they usually indicate that something is seriously 
>screwed up, so bailing out is probably for the best.

This is all very informative. Thanks for this.

>One thing that you need to remember if you are using native code is to 
>have GCC generate exception data for all your non-java code so that 
>faults in native code can be gracefully handled.

Can you explain what you mean by this? Doesn't this happen automatically
in C++?

Thanks again for your detailed answer.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]