stack overflow & null pointer exceptions

Wed Apr 21 09:09:00 GMT 1999

>> > From: Godmar Back <gback@cs.utah.edu>
> > Date: Wed, 7 Apr 1999 15:26:15 -0600 (MDT) 
> > 
> > Hi,
> > 
> > it appears that gcj does not yet implement stack overflow errors properly:
> > the following program segfaults. 
> > 
> > Apropos segfaulting: it also appears as though NullPointerExceptions aren't
> > properly caught (?). See the second test case.
>> NullPointerExceptions and ArithmeticExceptions are now caught on x86
> Linux and SPARC Solaris. I'm still considering what to do about stack
> overflows.
>
Andrew, did you try the test program I sent?
I updated and tried it on a Linux 2.2.5/glibc2.0.7 RH 5.2 box, and it 
still doesn't quite seem to work.
Here it is again:
/*
 * test that caught null pointers exceptions in finalizers work correctly
 * and that local variables are accessible in null pointer exception handlers.
 */
import java.io.*;
public class NullPointerTest {
 static String s;
 public static void main(String[] args) {
 System.out.println(tryfinally() + s);
 }
 public static String tryfinally() {
 String yuck = null;
 String local_s = null;
 try {
 return "This is ";
 } finally {
 try {
 local_s = "Perfect";
 /* trigger null pointer exception */
 String x = yuck.toLowerCase();
 } catch (Exception _) {
 /* 
 * when the null pointer exception is caught, we must still
 * be able to access local_s.
 * Our return address for the finally clause must also still
 * be intact.
 */
 s = local_s;
 }
 }
 }
}
/* Expected Output:
This is Perfect
*/
When run with the .java frontend, I see:
gback@peerless [24](/tmp) > gcj --main=NullPointerTest NullPointerTest.java
gback@peerless [25](/tmp) > ./a.out
Perfectnull
Ã‚Â° ... lots of garbage ...
When compiling the .class file only, I see:
gback@peerless [26](/tmp) > javac NullPointerTest.java 
gback@peerless [27](/tmp) > gcj --main=NullPointerTest NullPointerTest.class 
gback@peerless [28](/tmp) > ./a.out
This is Perfect
Ã‚Â° ... lots of garbage ...
This may not be a bug in the exception handling code; it looks more like
bugs in the java parser and in the gcj library (?)
	- Godmar