JDK-4984409 : assertion error occured in vtest run with fastdebug build 20040113204634.jmasa.g
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-01-28
  • Updated: 2009-11-16
  • Resolved: 2004-03-08
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.0 b42Fixed
Related Reports
Relates :  
JDK-6522315 - java_g hitting assertion while de-optimizing
Relates :  
JDK-6522316 - java_g hitting assertion while de-optimizing
Relates :  
JDK-6522319 - java_g hitting assertion while de-optimizing
Relates :  
JDK-6522318 - java_g hitting assertion while de-optimizing
Relates :  
JDK-6522317 - java_g hitting assertion while de-optimizing
Description
###@###.### 2004-01-27:

assertion error occured in vtest run in fastdebug build 20040113204634.jmasa.gc_baseline_merge-debug.

Test machine: 
bigapp-880-1.red.iplanet.com
SunOS bigapp-880-1 5.9 Generic_112233-07 sun4u sparc SUNW,Sun-Fire-880

fastdebug build version:
java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b32a)
Java HotSpot(TM) Server VM (build 20040113204634.jmasa.gc_baseline_merge-debug, compiled mode)

JVM flags: -server -Xcomp -XX:CompileOnly=java/net/Socket -XX:+UnlockDiagnosticVMOptions 
current thread: t@199-XX:+LogCompilation -XX:LogFile=<server-client-log>

Stack trace:
  [1] _libc_nanosleep(0xdf57e920, 0xdf57e918, 0x0, 0x0, 0x1, 0xdee6f4), at 0xff3
1af60
  [2] _sleep(0x64, 0xfecc9ef6, 0x1, 0x0, 0x5b, 0x3c), at 0xff37e328
  [3] os::infinite_sleep(0xff024850, 0xfecc9ef6, 0x1, 0x1, 0x1f, 0x64), at 0xfe1
72500
  [4] VMError::report_and_die(0xdf57eadc, 0x28bb8, 0xfef2bf8a, 0xff02e9f8, 0x291
38, 0x29c00), at 0xfe381db0
  [5] report_assertion_failure(0xfef2bf34, 0x67, 0xfef2bf8a, 0xfe17c23c, 0xfe16f
500, 0xbc5450), at 0xfdbd9cf0
  [6] xmlStream::begin_head(0x37c98, 0xfe6df0d2, 0x265b8, 0xfe6e0652, 0x2, 0xfef
64f78), at 0xfe39fb64
  [7] Deoptimization::uncommon_trap_inner(0xfe6e0652, 0xfffffff9, 0x2e4998, 0x2b
400, 0x2e45f8, 0xfef64f78), at 0xfdbf028c
  [8] Deoptimization::uncommon_trap(0x2e45f8, 0xfffffff9, 0xfffffff9, 0xf78260b0
, 0xfdccc944, 0xdf57f7d0), at 0xfdbf15f8
  [9] 0xf78abdf4(0xfffffff9, 0xef0040d8, 0x2134, 0x28e68, 0x27400, 0x28c00), at
0xf78abdf3
  [10] 0xf78c0bf0(0xf738c360, 0xef0040d8, 0x2134, 0x0, 0x3ec, 0x4), at 0xf78c0bef
  [11] 0xf78b1e40(0xf51a63c0, 0xb7, 0x1, 0xfe7d149c, 0x2e45f8, 0x6), at 0xf78b1e
3f
  [12] 0xf7805664(0xf67d2600, 0xb7, 0x0, 0xf78285f8, 0x3ec, 0xdf57f930), at 0xf7
805663
  [13] 0xf7805664(0xf67d2600, 0xb7, 0x0, 0xf78285f8, 0x2e45f8, 0xdf57f9b8), at 0
xf7805663
  [14] 0xf7805664(0xef013d00, 0xb7, 0x0, 0xf7828650, 0x0, 0xdf57fa48), at 0xf780
5663
  [15] 0xf7805664(0xef013d00, 0xeb02a5b0, 0x0, 0xf78284c0, 0xfe262924, 0xdf57fad
8), at 0xf7805663
  [16] 0xf7805b2c(0x35c, 0xfefee5e4, 0x0, 0xf7828c90, 0xfdd2c6a8, 0xdf57fb50), a
t 0xf7805b2b
  [17] 0xf78001c8(0xdf57fc3c, 0xdf57fe80, 0xa, 0xeb02b768, 0xf780de40, 0xdf57fda
8), at 0xf78001c7
  [18] JavaCalls::call_helper(0x1, 0xff01b8e0, 0xdf57fd9c, 0x2e45f8, 0xdf57fc18,
 0xdf57fc3c), at 0xfdd2c1a4
  [19] JavaCalls::call_virtual(0xdf57fe78, 0x26800, 0x2b270, 0x2b000, 0xdf57fd9c
, 0x2e45f8), at 0xfdd2ae88
  [20] JavaCalls::call_virtual(0x299e0, 0x29800, 0xdf57fe6c, 0xdf57fe68, 0xdf57f
e64, 0xff07dfb0), at 0xfdd2af3c
  [21] thread_entry(0x2e45f8, 0x2e45f8, 0xe, 0xeb02d3c8, 0xfef64f78, 0xfe95a972)
, at 0xfde41290
  [22] JavaThread::thread_main_inner(0x2e45f8, 0x0, 0xfefe9148, 0xfef64f78, 0x2a
454, 0x2e45f8), at 0xfe2f837c
  [23] _start(0x2e45f8, 0x29734, 0xc7, 0xfef64f78, 0x29400, 0xfe2f7e4c), at 0xfe16dff4

log and core files are saved under /export/archive/VolanoTestrun.20630 on machine bigapp-880-1.red.iplanet.com
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b42 tiger-beta2 VERIFIED IN: tiger-beta2
08-07-2004
EVALUATION This static data xtty is written by more than one thread concurrently. That's why the state is wrong and the assertion fires. I think a ttyLocker should be added to the deoptimization block under LogCompilation and in nmethod:: make_not_entrant_or_zombie() where it's used. ###@###.### 2004-02-20 Oh wait, there is a ttyLocker there. ###@###.### 2004-02-20 The root cause of this bug is an assertion in c2: Internal Error at callGenerator.cpp:34, pid=22645, tid=16 that turns off the ttyLocker, which causes these assertions in the xml code. LogCompilation and TraceDeoptimization should probably be turned off if there's a error or maybe xtty should be zeroed (since there are careful checks for zero). ###@###.### 2004-02-20 Instead of turning off the logs, for which a race still exists, I think that turning off the assertions if is_error_reported() would be better. That way the output would still come out, which may be useful in diagnosing the error. The xml may be not be valid though but it's better than not coming out. Ross or John do you have an opinion on this??? ###@###.### 2004-02-23 ###@###.### 2004-02-23 Yes, just disabling the xml assertions when is_error_reported is true seems like a good idea. It would be nice to get the output even if it is a bit scrambled. When a VM error occurs, the code that prints out information for LogCompilation in xml format asserts that the xml tags aren't in the right order. This is because once a VM error happens, the ttyLocker is not held and the sequencing for the xml printing isn't enforced. This fix turns off the state assertions in the xml stream so that the output comes out anyway and the VM doesn't get other errors on the printing code. ###@###.### 2004-03-02
02-03-2004