Name: bsC130419			Date: 06/05/2001


java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b65)
Java HotSpot(TM) Client VM (build 1.4.0-beta-b65, mixed mode)

This is a resubmission of bug #124860.

All the following tests were done on two linux boxes:

1) Red Hat Linux 7.0 (Guinness) using kernel 2.2.16-22 runing on a P-III 733MHz.
 GNOME 1.2 is the desktop environment.  This was installed about four months ago
and has run in a very stable since.

2) Linux Mandrake 8.0 (Traktopel) using kernel 2.4.3-20mdk #1 running on an
Athlon-C 1333MHz. GNOME 1.4 is the desktop environment.  This install is
relativly fresh (the only non-standard packages loaded are J2SDK1.4.0, pine, and
Folding@Home).

I have not tried to replicate the bug on any other distribution or system.  The
bug does not appear with JDK 1.2.2 or the IBM JDK 1.3.0; I do not know about
other JDK's since these where the only two on hand at the time.

The following code snipped incorrectly produces a segmentation fault insteam of
a StackOverflowError:

public class SegFaultTest
{

    public static void main(String[] args)
    {
        new SegFaultTest();
    }

    public SegFaultTest()
    {
        new SegFaultTest();
    }

}

It was compiled and run with:

javac SegFaultTest.java
java SegFaultTest

And produced:
Segmentation fault

As noted previously, this also occurs under other conditions, such as a
NullPointerException.  It seems to occur when there are deeply recursive calls
during construction.  I have managed to construct another code snipped that
demonstrates this situation:

public class SegFaultTestNpe
{

    public static void main(String[] args)
    {
        new SegFaultTestNpe(Integer.parseInt(args[0]));
    }

    public SegFaultTestNpe(int depth)
    {
        if (depth == 0)
        {
            ((String)null).length();
        }
        else
        {
            new SegFaultTestNpe(depth - 1);
        }
    }

}

It was compiled and run with:

javac SegFaultTestNpe.java
java SegFaultTestNpe <depth>

With the value for <depth> between 0 and 423 inclusive, it generates the
expected NullPointerException and stack trace.  With a value of 424 however, a
segmentation fault is generated.

Also, this is not restricted to occuring in constructors as previously thought.
 It also occurs with exceptions thrown during normal recursive code, such as:

public class SegFaultTestNpeNc
{

    public static void main(String[] args)
    {
        SegFaultTestNpeNc sf = new SegFaultTestNpeNc();
        sf.recurse(Integer.parseInt(args[0]));
    }

    public SegFaultTestNpeNc()
    {
    }

    public void recurse(int depth)
    {
        if (depth == 0)
        {
            ((String)null).length();
        }
        else
        {
            recurse(depth - 1);
        }
    }

}

I can probably construct further examples based around the same idea.  When you
actually write correct recursive algorithms, they provide the correct result.
The problem only occurs when there is an exception thrown deep in a recursive
call.  The most worrying thing about this bug is that there are situations that
an exception is thrown and should be handled in deep recursion.  Simply replace
the line "((String)null).length();" in the above snipped with "throw new
IOException();", (makeing the corresponding changes to the method declarations
as well) and the same error will occur.

If this bug is something peculiar to both these systems listed, it is probably a
very good idea to try and track down what exactly is causing this problem as it
seems to be more common than on one linux install on one type of machine using a
specific kernel version.  The only idea that I can offer is that because the
stack trace itself is so long, it may be longer than some internal, undocumented
limit and this is causing an overrun in native code somewhere.
(Review ID: 125179) 
======================================================================