JDK-6400206 : HotSpot Virtual Machine crashes when using multiple connexions/sockets to handle network traffic.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 5.0u6
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2006-03-17
  • Updated: 2010-07-29
  • Resolved: 2006-04-21
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
5.0u8Resolved
Related Reports
Duplicate :  
Description
When receiving network traffic through multiple connexions, the test-case in attachment (Test.jar) crashes in about one hour with the following message:
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  Internal Error (50532D41524B33574545502445434F5241544F520E4350500032), pid=15387, tid=6 # # Java VM: Java HotSpot(TM) Server VM (1.5.0_06-b05 mixed mode)

The problem was also reported on the Sun Developer Network, id 653578.

The attached test case is executed with the following command:

$ java -Xmx3500m -Xms3500m -jar -cp .:Test.jar Test.jar

Also in attachment the error log file: hs_err_pid5750.log

Comments
SUGGESTED FIX Do we have a target date for 5.0_08? Thanks, Thierry
14-04-2006

WORK AROUND The customer installed Java 1.6 (Mustang) in its environment and could run the test-case without any problem. Thierry
14-04-2006

SUGGESTED FIX I'll request for a backport of CR 6253746 to 5.0_08.
05-04-2006

WORK AROUND The customer is encouraged to at least try out a recent Mustang binary to confirm that it works as advertised for them.
05-04-2006

EVALUATION An assertion failure with a fastdebug 5.0_06 build showed that the cause of the problem seems to be the bug reported in CR 6253746 which was fixed in Mustang (b37). Here's the stack trace: _start(0x1f6848, 0x2d074, 0x12, 0xfeec2804, 0x2d000, 0xfe0dc850) VMThread::run(0x1f6848, 0x2b548, 0x2b400, 0x2bf58, 0x2d074, 0x3a840) VMThread::loop(0x1f6848, 0x15e7f3b4, 0xfef9808c, 0xfef98088, 0x2c000, 0x2b800) VMThread::evaluate_operation(0x12a630, 0x15e7f3b4, 0x1f6930, 0x2dc00, 0x12a620, 0x2b288) VM_Operation::evaluate(0x15e7f3b4, 0x2ee1c, 0x1f6930, 0x12aa1c, 0xfef50eb4, 0x0) VM_ParallelGCFailedAllocation::doit(0x15e7f3b4, 0xc7168, 0xc7270, 0xfeec2804, 0x2, 0xfee707fa) ParallelScavengeHeap::failed_mem_allocate(0xc7168, 0x15e7f3d0, 0x8, 0x0, 0x0, 0x0) PSScavenge::invoke(0x15e7f3d0, 0x7, 0xc7168, 0xfeec2804, 0xc7270, 0xfef82788) PSMarkSweep::invoke_no_policy(0x15e7f3d0, 0xc7568, 0xc9348, 0xc9bb8, 0xc7568, 0xc74f0) PSOldGen::precompact(0xc7568, 0xfef76bbc, 0xfeec2804, 0xfef8dd24, 0x2ef78, 0x2ec00) PSMarkSweepDecorator::precompact(0x18800ad0, 0xfef7b6d4, 0x1c856968, 0xae1306f8, 0xc8b10, 0x1c856968) PSMarkSweepDecorator::insert_deadspace(0xe4636760, 0x1c85696c, 0x1c856968, 0x18800ad0, 0xe4636764, 0xfebfaaea) report_assertion_failure(0xfebfa93a, 0x118, 0xfebfa9d3, 0x2cd1c, 0xfeec2804, 0x2cc00) VMError::report_and_die(0x1727f484, 0x2b3f8, 0x2d38c, 0x2b000, 0x2b90c, 0xfef9c858) VMError::show_message_box(0x1727f484, 0xfef9c080, 0x7d0, 0xfe0c6ee4, 0x27000, 0x40) os::message_box(0x1edf8, 0xfef9c080, 0x1727f248, 0xfef755ac, 0xfeec2804, 0x2cc00) read(0x0, 0x1727f248, 0x10, 0x0, 0x4f, 0x0) _read(0x0, 0x1727f248, 0x10, 0x0, 0x1fc, 0x1ad) and the assertion: Internal Error at psMarkSweepDecorator.cpp:280, pid=6466, tid=18 assert(((deadlength - aligned_min_int_array_size) * (HeapWordSize/sizeof(jint))) < max_jint, "deadspace too big for Arrayoop"); Additionally, I have not been able to reproduce this bug with the latest Mustang build. *** (#1 of 1): [ UNSAVED ] ###@###.###
05-04-2006