JDK-6346701 : stack overflow in native method results in segfault, not a StackOverflowError
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86
  • Submitted: 2005-11-07
  • Updated: 2011-02-22
  • Resolved: 2010-10-08
Related Reports
Duplicate :  
JDK-6983240 - guarantee((Solaris::min_stack_allowed >= (StackYellowPages+StackRedPages...) wrong
Description
FULL PRODUCT VERSION :
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Server VM (build 1.5.0_05-b05, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Linux p3 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:32:14 EDT 2005 i686 i686 i386 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
When looking up web64.miraclehosting.com, which has 123 ip addresses, I was getting segfaults.  It took me a while to realize that my small stack size was causing a problem in glibc code.  I was getting core dumps, which weren't caught by the jre handler that usually catches them, and it took me a long time to figure out what was going on.  Now that I know the workaround is obvious, but without the StackOverflowError (or an OutOfMemoryError) It took me over a week to figure out.

Thanks to Jakub Jelinek at Redhat for helping me figure this out.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
java -Xss60k InetOverflow web64.miraclehosting.com


ACTUAL -
(gdb) bt
#0  *__GI_getaddrinfo (name=0x81e0a50 "web64.miraclehosting.com",
service=0x7d77ac8a "domain", hints=0x7c6646f4, pai=0x7c6646f0)
    at ../sysdeps/posix/getaddrinfo.c:1593
#1  0x7d76ef08 in Java_java_net_Inet6AddressImpl_lookupAllHostAddr () from
/usr/local/jdk1.5.0_05/jre/lib/i386/libnet.so
#2  0xb22b6838 in ?? ()
#3  0x7b6ea55c in ?? ()
#4  0x7c664780 in ?? ()
#5  0x7c66477c in ?? ()
#6  0x7c664750 in ?? ()
#7  0x00000000 in ?? ()

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Segmentation fault (core dumped)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public final class InetOverflow {
    public static void main(final String[] args)throws Exception {
        for(int i = 0; i < args.length; i++){
            java.net.InetAddress.getAllByName(args[i]);
        }
    }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Make sure to use large stack sizes.
Comments
EVALUATION This was left open because of strange behaviour with specifying small stack sizes and different values of StackShadowPages. This was because of infinite recursion throwing stack overflow before it was initialized. This bug was fixed with 6983240. I'm closing this as a duplicate of that so as not to confuse the robots.
08-10-2010
WORK AROUND Increase stack size..-Xss???
27-04-2006
EVALUATION Nelson, can you attach InetOverflow.java or get it from customer??
26-04-2006
EVALUATION From the JDC comments, this bit surprised me: [root@p3 /tmp]# java -XX:StackShadowPages=7 -Xss68k InetOverflow web64.miraclehosting.com Segmentation fault [root@p3 /tmp]# java -XX:StackShadowPages=7 -Xss69k InetOverflow web64.miraclehosting.com [root@p3 /tmp]# java -Xss69k InetOverflow web64.miraclehosting.com We should be able to throw stack overflow error with 7 shadow pages even when the initial stack size is too small. Can you attach InetOverflow.java? [root@p3 /tmp]# java -XX:StackShadowPages=9 -Xss68k InetOverflow web64.miraclehosting.com Error occurred during initialization of VM java.lang.NullPointerException This is interesting too. We should give more information for vm initialization errors.
03-03-2006
EVALUATION Asked for more info 1+ months ago.. Please try what is asked in eval and let us know if this helps any. We will be closing soon.
09-02-2006
EVALUATION The Hotspot VM detects stack overflow in Java code, but since the user's and some jdk native code is not written in Java, that does not check the stack to detect overflow. Since the VM uses the current stack to throw StackOverflowError, there needs to be some stack present, which is why the VM checks a few pages down the stack. Since we don't have knowledge of how deep a user's native stack may be, the Hotspot VM provides a tunable parameter -XX:StackShadowPages=n. Set 'n' to be the approximate depth, in pages, of the native stack so that the VM can throw stack overflow when it's exceeded. The default on x86 platforms is 3, which appears to be too small for the native stack in the description (subtract sp frame 0 from sp in frame 7 and divide by pagesize which I think is 0x2000). The other thing to do is increase stack size with -Xss<n>.
03-01-2006