United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4479571 JVM core dumps after receiving out of memory messages
JDK-4479571 : JVM core dumps after receiving out of memory messages

Details
Type:
Bug
Submit Date:
2001-07-13
Status:
Closed
Updated Date:
2009-06-25
Project Name:
JDK
Resolved Date:
2001-10-18
Component:
hotspot
OS:
solaris_7
Sub-Component:
runtime
CPU:
sparc
Priority:
P2
Resolution:
Duplicate
Affected Versions:
1.3.0_03
Fixed Versions:
1.3.1_03

Related Reports
Duplicate:
Relates:
Relates:

Sub Tasks

Description
This problem is present in both 1.3.0_02 1.3.0_03 and 1.3.1

Changing the time-stamp of a servlet deployed in WebLogic 6's
public_html/WEB-INF/classes/ directory triggers the OutOfMemory errors and
the eventual HotSpot crash.

When a servlet is changed, WebLogic 6's code destroys its current class
loader object and instantiates a new one.  This requires any session objects
in memory to be serialized before the class loader is destroyed, then
deserialized and reinstantiated for the new class loader.  (This is
documented at
http://e-docs.bea.com/wls/docs60////servlet/progtasks.html#143031 under the
"ClassCastException and HTTP Sessions" header).

There is a lot of serialization/deserialization happening all at once, which
is what we suspect is causing the problem.

This problem happens with any of the flags -client, -server or -hotspot

java.lang.OutOfMemoryError
	<<no stack trace available>>
<Jul 9, 2001 9:51:02 AM EDT> <Error> <HTTP> <[WebAppServletContext(2378821,public_html)] Servlet failed with Exception
java.lang.OutOfMemoryError
	<<no stack trace available>>
> 
java.lang.OutOfMemoryError
	<<no stack trace available>>
<Jul 9, 2001 9:51:02 AM EDT> <Error> <HTTP> <[WebAppServletContext(2378821,public_html)] Servlet failed with Exception
java.lang.OutOfMemoryError
	<<no stack trace available>>
> 
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Error ID: 4349254E560E43505000F4 01
#
# Problematic Thread: prio=5 tid=0x100ae0 nid=0xb runnable 
#

========
dbx output of thread
current thread: t@11
=>[1] __sigprocmask(0x0, 0xfea01f38, 0x0, 0xffffffff, 0xffffffff, 0x0), at 0xff379cf0
  [2] _resetsig(0xff38c984, 0x0, 0xfea03dc0, 0x0, 0x0, 0xfea03e40), at 0xff36f31c
  [3] _sigon(0xff3943d8, 0xff394278, 0xfea03e38, 0xfea0200c, 0x6, 0xff2cd0ac), at 0xff36ea40
  [4] _thrp_kill(0x0, 0xb, 0x6, 0xff38c984, 0xfea03dc0, 0xff393bf4), at 0xff371944
  [5] abort(0xff333bb0, 0xfea02100, 0x0, 0xfffffff8, 0x0, 0xfea02121), at 0xff2b9468
  [6] os::abort(0x1, 0xfe78c000, 0x1, 0xfea02, 0xfe78c000, 0xfea0211c), at 0xfe6e28ac
  [7] report_error(0xee, 0xfea02992, 0xf4, 0xfe73eca4, 0xfe7c6df8, 0xfe78c000), at 0xfe650ae0
  [8] report_fatal(0xf4, 0xfe78c000, 0xfe762218, 0xfea03344, 0x100ae0, 0x2), at 0xfe6503b0
  [9] ciEnv::get_constant_by_index_impl(0x0, 0x100ae0, 0xfea03b78, 0x2, 0xfe78c000, 0xfea033b0), at 0xfe5d7880
  [10] ciEnv::get_constant_by_index(0xfe79f8ec, 0x100ae0, 0xfea03438, 0x2, 0xfe78c000, 0x1f5f08), at 0xfe5d75ec
  [11] ciBytecodeStream::get_constant(0x1f5f08, 0xfea03b78, 0xfe78c000, 0xfea034b0, 0xfea03550, 0x2), at 0xfe5d74d
4
  [12] GraphBuilder::load_constant(0xfe78c000, 0x100fa0, 0xfea035d4, 0x100f98, 0x100f94, 0x100f90), at 0xfe5d6f84
  [13] GraphBuilder::connect_to_end(0xfe7b8fac, 0xfe7b8fb0, 0xfe7b8fb4, 0xfe7b8fb8, 0xfe7b8fbc, 0xfe78c000), at 0x
fe5acf54
  [14] GraphBuilder::handle_exception(0xda9d78, 0xdaa8b0, 0xdaa99c, 0xfe78c000, 0xffffffff, 0xfe7b0c3c), at 0xfe5d
477c
  [15] GraphBuilder::connect_to_end(0xfe7b8fac, 0xfe7b8fb0, 0xfe7b8fb4, 0xfe7b8fb8, 0xfe7b8fbc, 0xfe78c000), at 0x
fe5ac300
  [16] GraphBuilder::GraphBuilder(0xda9ea0, 0xfea03a98, 0x100fd0, 0xda9cd4, 0xda9de4, 0xfea03770), at 0xfe5abbc0
  [17] IRScope::build_graph(0xda9e50, 0xfea03a98, 0xffffffff, 0x1f4f60, 0xfe78c000, 0xfe78c000), at 0xfe5aa970
  [18] IR::IR(0xda9ccc, 0xfea03a98, 0x1f5ec0, 0xda9cb8, 0x100fd0, 0x100dd0), at 0xfe5a9ba4
  [19] Compilation::build_hir(0x100f7c, 0xfe78c000, 0xfea03a98, 0xfea03ba4, 0x400, 0xfffffffc), at 0xfe5a9984
  [20] Compilation::compile_java_method(0xfea03a98, 0xfea03a1c, 0xfea03a98, 0x100ae0, 0xfea03ba4, 0xfea039cc), at 
0xfe5a8a18
  [21] Compilation::Compilation(0x100ca0, 0xfea03b78, 0x1f5ec0, 0xffffffff, 0x100c84, 0xfe78c000), at 0xfe5a8440
  [22] Compiler::compile_method(0x100c84, 0x100c18, 0xfe78c000, 0x1f5ec0, 0xffffffff, 0x1f5ec0), at 0xfe5a81a0
  [23] CompileBroker::invoke_compiler_on_method(0x1f5ec0, 0x0, 0xfe7ab604, 0x0, 0x0, 0xa48), at 0xfe5a3a98
  [24] CompileBroker::compiler_thread_loop(0x29128, 0x100ae0, 0xfe78c000, 0xfea03d60, 0xfe78c000, 0xf9cf5130), at 
0xfe59df70
  [25] JavaThread::run(0xfe904000, 0xfe795d3c, 0xfe78c000, 0x100000, 0x100ae0, 0x100000), at 0xfe58e040
  [26] _start(0xfe78c000, 0xff255d60, 0x0, 0xb8681e50, 0x1, 0xfe401000), at 0xfe57dea4



All info (java_g core file and dbx output(newdbxout) and error logs) are contained in
/net/cores.east/cores/62553685


                                    

Comments
EVALUATION

Not enough info to reproduce this. I do not use WebLogic 6 product, and I have no idea where to find such servlet stuff.  Downloaded 6.0 and installed it.
Started up fine, waiting for servlet info.  Please provide a demo
servlet to use and steps to get it up and running. 
gary.collins@East 2001-08-01

Picked up from Ireland. Looking for causes of OutOfMemory.
Requested that customer add -verbosegc and provide
the output.

###@###.### 2001-09-21

After applying fixes for bugs 4490177,4484290 and 4503832, the customer
no longer sees a SEGV. The problem is now a hang. If we don't see this
problem again, I am closing the bug as a dup of 4503832.

###@###.### 2001-10-17
                                     
2001-10-17
PUBLIC COMMENTS

JVM SEGV - Related to Bug# 4503832
                                     
2004-06-10
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
1.3.1_03

FIXED IN:
1.3.1_03

INTEGRATED IN:
1.3.1_03


                                     
2004-06-14



Hardware and Software, Engineered to Work Together