-
Bug
-
Resolution: Other
-
P4
-
1.3.1_07, 1.4.0, 1.4.1, 1.4.1_01, 1.4.1_02, 1.4.2
-
b81
-
generic, x86, sparc
-
generic, solaris_7, solaris_8, solaris_9, windows_2000
--------------------------------------
Test : nsk/regression/b4432433
TestBase : testbase_nsk
VM : server , client
Mode : comp . mixed
Platform (s) : solx86 , rh7.2
----------------------------------------
Error output (for solx86)
sh std-doit.sh
/net/alpheridies/export/VM/hopper/weekly/JDK/latest/solx86/bin/java -client -DHA
NGINGJAVA -client -Xmixed -Xmx1024m b4432433 1024
Exception java.lang.OutOfMemoryError: requested 1048592 bytes
Status = 1
------------------------------------------------
/net/alpheridies/export/VM/hopper/weekly/JDK/latest/solx86/bin/java -client -DHA
NGINGJAVA -client -Xcomp -Xmx1024m b4432433 1024
Exception java.lang.OutOfMemoryError: requested 1048592 bytes
Status = 1
------------------------------------------------
/net/alpheridies/export/VM/hopper/weekly/JDK/latest/solx86/bin/java -server -DHA
NGINGJAVA -server -Xmixed -Xmx1024m b4432433 1024
Exception java.lang.OutOfMemoryError: requested 28835840 bytes
Status = 1
------------------------------------------------
/net/alpheridies/export/VM/hopper/weekly/JDK/latest/solx86/bin/java -server -DHA
NGINGJAVA -server -Xcomp -Xmx1024m b4432433 1024
Exception java.lang.OutOfMemoryError: requested 28835840 bytes
Status = 1
------------------------------------------------
***** Please Note*******
This has been reported since 1.4.1-beta-b06. THe information was added to an exiting bug b4432433. Since that bug was already in Integrated state when this additonal comment was added, not sure if this is getting tracked. Hence
Opening a new bug for better tracking
************************************
Steps to reproduce:
----------------------
1. cd /net/sqesvr.eng/export/vsn/GammaBase/Bugs/{BugID}
2. sh doit.sh
###@###.### 2002-06-05
###@###.### 2003-04-24
In the past, we have seen VM exits that appeared
to be due to running out of memory (no OutOfMemory
exception - just a VM exit). A little digging on this
led us to the following bug report:
http://developer.java.sun.com/developer/bugParade/bugs/4697804.html
The specific problem described in this bug that concerns us
is the potential for the VM to simply exit when it can't
expand the heap, rather than throw an OutOfMemory exception
that would allow the application to continue and/or recover.
We are doing our best to work around this by following the
recommended practices of configuring enough swap and setting
-Xms equal to -Xmx. Unfortunately we can't really control our
customers swap configurations (can only make recommendations) and
so we feel compelled to use the Xms = Xmx workaround which is
really inefficient in many cases.
###@###.### 10/27/04 21:58 GMT
Test : nsk/regression/b4432433
TestBase : testbase_nsk
VM : server , client
Mode : comp . mixed
Platform (s) : solx86 , rh7.2
----------------------------------------
Error output (for solx86)
sh std-doit.sh
/net/alpheridies/export/VM/hopper/weekly/JDK/latest/solx86/bin/java -client -DHA
NGINGJAVA -client -Xmixed -Xmx1024m b4432433 1024
Exception java.lang.OutOfMemoryError: requested 1048592 bytes
Status = 1
------------------------------------------------
/net/alpheridies/export/VM/hopper/weekly/JDK/latest/solx86/bin/java -client -DHA
NGINGJAVA -client -Xcomp -Xmx1024m b4432433 1024
Exception java.lang.OutOfMemoryError: requested 1048592 bytes
Status = 1
------------------------------------------------
/net/alpheridies/export/VM/hopper/weekly/JDK/latest/solx86/bin/java -server -DHA
NGINGJAVA -server -Xmixed -Xmx1024m b4432433 1024
Exception java.lang.OutOfMemoryError: requested 28835840 bytes
Status = 1
------------------------------------------------
/net/alpheridies/export/VM/hopper/weekly/JDK/latest/solx86/bin/java -server -DHA
NGINGJAVA -server -Xcomp -Xmx1024m b4432433 1024
Exception java.lang.OutOfMemoryError: requested 28835840 bytes
Status = 1
------------------------------------------------
***** Please Note*******
This has been reported since 1.4.1-beta-b06. THe information was added to an exiting bug b4432433. Since that bug was already in Integrated state when this additonal comment was added, not sure if this is getting tracked. Hence
Opening a new bug for better tracking
************************************
Steps to reproduce:
----------------------
1. cd /net/sqesvr.eng/export/vsn/GammaBase/Bugs/{BugID}
2. sh doit.sh
###@###.### 2002-06-05
###@###.### 2003-04-24
In the past, we have seen VM exits that appeared
to be due to running out of memory (no OutOfMemory
exception - just a VM exit). A little digging on this
led us to the following bug report:
http://developer.java.sun.com/developer/bugParade/bugs/4697804.html
The specific problem described in this bug that concerns us
is the potential for the VM to simply exit when it can't
expand the heap, rather than throw an OutOfMemory exception
that would allow the application to continue and/or recover.
We are doing our best to work around this by following the
recommended practices of configuring enough swap and setting
-Xms equal to -Xmx. Unfortunately we can't really control our
customers swap configurations (can only make recommendations) and
so we feel compelled to use the Xms = Xmx workaround which is
really inefficient in many cases.
###@###.### 10/27/04 21:58 GMT
- duplicates
-
JDK-4816658 Crash - Unexpected Signal : 10 occurred at PC=0xFA493DE4
-
- Closed
-
- relates to
-
JDK-4317486 [sol/c1/b04] assert generation.cpp 469 during scavenge.
-
- Closed
-
-
JDK-4719001 all collectors should implement Generation::commit_contiguous_available
-
- Closed
-
-
JDK-6405799 JVM Exits with OutOfMemoryError for vm\utilities\growableArray.cpp
-
- Closed
-
-
JDK-4432433 javadoc run in build on linux crashes jvm (gnumake all docs)
-
- Closed
-