Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4466587

JVM causes segmentation fault on Mandrake 8.0, SuSE 7.2


    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 1.3.1, 1.4.0
    • Fix Version/s: 1.4.0
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Resolved In Build:
    • CPU:
    • OS:


      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

      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)
                  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();

          public SegFaultTestNpeNc()

          public void recurse(int depth)
              if (depth == 0)
                  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)


          Issue Links



              • Assignee:
                hhuangsunw Hui Huang (Inactive)
                bstrathesunw Bill Strathearn (Inactive)
              • Votes:
                0 Vote for this issue
                0 Start watching this issue


                • Created: