JDK-4821821 : SuSe8: 2 plumhall-99a/jvs cases fail on SuSe8
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.3.1_13,1.4.2
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: other,linux_suse_sles_8
  • CPU: x86
  • Submitted: 2003-02-21
  • Updated: 2004-09-16
  • Resolved: 2003-03-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 b18Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
Filed By       : J2SE-SQA 
JDK            : JDK1.4.1 , JDK1.4.2 b16
Platform[s]    : SuSe8.0 KDE3.0 
switch/Mode    : -cleint
testbase       :/net/sqesvr/export/xlt/Tools/mantis/testbase
Falling test[s]: 
plumhall-99a/jvs/ch11/j114p11s_x
plumhall-99a/jvs/lang/StackOverflowError/CX_String_01_x


CX_String_01_x error messages when testing with JDK1.4.2:
/net/koori.sfbay/p/jdk01/jdk/1.4.2/beta/b16/binaries/linux-i586/bin/java -client jvs.lang.Sta
ckOverflowError.CX_String_01_x.CX_String_01_x
##Exit status of execution step=129
##!checkExitCode

#
#*** JVS(R): The Plum Hall Test Suite for The Java(tm) Language, Util(513)
##Begin Case (jvs.lang.StackOverflowError.CX_String_01_x.CX_String_01_x)
##Reached first test (line 62)
##
## HotSpot Virtual Machine Error, Internal Error
## Please report this error at
## http://java.sun.com/cgi-bin/bugreport.cgi
##
## Java VM: Java HotSpot(TM) Client VM (1.4.2-beta-b16 mixed mode)
##
## Error ID: 4F533F4C494E55583F491418160E43505000B8
##
## Problematic Thread: prio=1 tid=0x08052680 nid=0x48a6 runnable
##
#
#Heap at VM Abort:
#Heap
# def new generation   total 576K, used 185K [0x44700000, 0x447a0000, 0x44be0000)
#  eden space 512K,  36% used [0x44700000, 0x4472e558, 0x44780000)
#  from space 64K,   0% used [0x44780000, 0x44780000, 0x44790000)
#  to   space 64K,   0% used [0x44790000, 0x44790000, 0x447a0000)
# tenured generation   total 1408K, used 0K [0x44be0000, 0x44d40000, 0x48700000)
#   the space 1408K,   0% used [0x44be0000, 0x44be0000, 0x44be0200, 0x44d40000)
# compacting perm gen  total 4096K, used 995K [0x48700000, 0x48b00000, 0x4c700000)
#   the space 4096K,  24% used [0x48700000, 0x487f8e50, 0x487f9000, 0x48b00000)



CX_String_01_x error messages when testing with JDK1.4.1:
/net/koori.sfbay/p/jdk09/jdk/1.4.1/fcs/b21/binaries/linux-i586/bin/java -server jvs.lang.StackOverflowError.CX_String_01_x.CX_String_01_x
##Exit status of execution step=129
##!checkExitCode

#
#*** JVS(R): The Plum Hall Test Suite for The Java(tm) Language, Util(513)
##Begin Case (jvs.lang.StackOverflowError.CX_String_01_x.CX_String_01_x)
##Reached first test (line 62)

CX_String_01_x.tlog & j114p11s_x.tlog are attached.

Test Machine Config:
======================
seahund: SuSE Linux 8.0 (i386) - Kernel 2.4.18-4GB (6).
lexington: SuSE Linux 8.0 (i386) - Kernel 2.4.18-4GB (2).

###@###.### 2003-02-20

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis-beta FIXED IN: mantis-beta INTEGRATED IN: mantis-b18 mantis-beta tiger-beta VERIFIED IN: mantis-beta
17-09-2004

WORK AROUND as root: echo 0 > /proc/sys/vm/heap-stack-gap
17-09-2004

EVALUATION This is a known issue in SuSE kernel. See 4345034. Set heap-stack-gap to 0 if you have root priviledge. ###@###.### 2003-02-21 -------------------------------------------- The problem is that SuSE build their kernels with silent-stack-overflow patch. This patch assumes the last memory region is stack and the second last one belongs to heap. It tries to avoid silent heap-stack collision by maintaining a hidden "gap" between the last two memory regions. Touching pages within the gap will generate a SEGV. The gap size is determined by /proc/sys/vm/heap-stack-gap. Heap-stack gap is disabled if this file doesn't exist or if its value is 0. However, in HotSpot (and most MT applications), the last two memory regions belong to initial thread's stack and its guard pages. So heap-stack gap is in fact a gap between initial thread's stack and its guard pages. We could hit heap-stack-gap in stack banging and die with a SEGV. See Suggested Fix for a possible workaround in JVM. It's based on a similar change from blackdown. ###@###.### 2003-02-26 --------------------------------------------- In tiger, we use a different mechanism to fix the problem. The silent-stack-overflow patch attempts to detect heap-stack collision when expanding initial thread stack. In tiger, we'll first force kernel to map the entire initial thread stack during VM initialization, and then put a guard page right below initial stack, so there is no gap between the two memory regions, and no stack expansion that can trigger the SuSE patch. ###@###.### 2003-09-23
23-09-2003

SUGGESTED FIX see attachment (webrev.tgz) ###@###.### 2003-02-26
26-02-2003