Submitting a HotSpot VM error

I've never read the boilerplate on Sun's "Re: (Incident Review ID..." mails before. I've always replied to requests for more information assuming that there was some point to doing so.

I recently submitted the following bug report:

dateCreated: Sun Oct 23 20:22:03 MDT 2005
type: bug
cust_name: Elliott Hughes
status: Waiting
category: hotspot
subcategory: runtime_system
release: 5.0
hardware: sparcv9
OSversion: solaris_10
priority: 4
synopsis: HotSpot VM error in xiiimp.so.2
See hs_pid output.

SunOS helium 5.10 Generic_118844-19 i86pc i386 i86pc

I don't remember this crash, but I just found a core dump and an hs_pid file.



I ran the Sun(TM) Update Manager.

# An unexpected error has been detected by HotSpot Virtual Machine:
# SIGSEGV (0xb) at pc=0xed9868f2, pid=7756, tid=11
# Java VM: Java HotSpot(TM) Client VM (1.5.0_01-b08 mixed mode)
# Problematic frame:
# C [xiiimp.so.2+0x68f2]

--------------- T H R E A D ---------------

Current thread (0x08884a38): JavaThread "AWT-Motif" daemon [_thread_in_native, id=11]

siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000024

EAX=0x00000014, EBX=0x00008000, ECX=0x08d90438, EDX=0xed90b970
ESP=0xed90b930, EBP=0xed90b930, ESI=0x08c492d8, EDI=0x0000000c
EIP=0xed9868f2, EFLAGS=0x00010206

Top of Stack: (sp=0xed90b930)
0xed90b930: ed90b954 edbedf86 085e8f00 03e0006c
0xed90b940: ed90b970 08d90438 08884af4 edf31500
0xed90b950: edf2e000 ed90ba40 eded3cea ed90b970
0xed90b960: 00000000 08884af4 00000007 edf2e000
0xed90b970: 0000000c 00000512 00000000 085e8f00
0xed90b980: 03e0006c 00000000 00000000 000000b4
0xed90b990: 00000017 00000000 36373931 5c3b302d
0xed90b9a0: 2020200a 20202020 75732d20 6f672d6e

Instructions: (pc=0xed9868f2)
0xed9868e2: 55 8b ec 8b 4d 14 8b 81 08 01 00 00 85 c0 74 0e
0xed9868f2: 83 78 10 00 74 08 6a 00 51 e8 76 01 00 00 b8 01

Stack: [0xed8cc000,0xed90c000), sp=0xed90b930, free space=254k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [xiiimp.so.2+0x68f2]
C [libX11.so.4+0x2df86] XFilterEvent+0x72
C [libmawt.so+0x13cea]
C [libmawt.so+0x136d6]
C [libmawt.so+0x13574] Java_sun_awt_motif_MToolkit_run+0x34
j sun.awt.motif.MToolkit.run()V+0
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
V [libjvm.so+0xa71e7]
V [libjvm.so+0xa7054]
V [libjvm.so+0xa7038]
V [libjvm.so+0xb38ae]
V [libjvm.so+0xb37dd]
V [libjvm.so+0xb3750]
V [libjvm.so+0xb3651]
V [libjvm.so+0xb35e8]
V [libjvm.so+0xa5af2]
C [libc.so.1+0x9f525]
C [libc.so.1+0x9f810]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j sun.awt.motif.MToolkit.run()V+0
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub

--------------- P R O C E S S ---------------

Java Threads: ( => current thread )
0x08a724d8 JavaThread "AWT-EventQueue-0" [_thread_blocked, id=13]
0x088bcc90 JavaThread "Image Fetcher 0" daemon [_thread_blocked, id=12]
=>0x08884a38 JavaThread "AWT-Motif" daemon [_thread_in_native, id=11]
0x08884560 JavaThread "AWT-Shutdown" [_thread_blocked, id=10]
0x085e9738 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=9]
0x081462c8 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=7]
0x08143930 JavaThread "CompilerThread0" daemon [_thread_blocked, id=6]
0x08142c78 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=5]
0x08137208 JavaThread "Finalizer" daemon [_thread_blocked, id=4]
0x08136660 JavaThread "Reference Handler" daemon [_thread_blocked, id=3]
0x08072dd8 JavaThread "main" [_thread_blocked, id=1]

Other Threads:
0x08133e18 VMThread [id=2]
0x08160c78 WatcherThread [id=8]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

def new generation total 576K, used 407K [0xef200000, 0xef2a0000, 0xef6e0000)
eden space 512K, 67% used [0xef200000, 0xef255cc8, 0xef280000)
from space 64K, 100% used [0xef280000, 0xef290000, 0xef290000)
to space 64K, 0% used [0xef290000, 0xef290000, 0xef2a0000)
tenured generation total 1408K, used 1071K [0xef6e0000, 0xef840000, 0xf3200000)
the space 1408K, 76% used [0xef6e0000, 0xef7ebd38, 0xef7ebe00, 0xef840000)
compacting perm gen total 8192K, used 6670K [0xf3200000, 0xf3a00000, 0xf7200000)
the space 8192K, 81% used [0xf3200000, 0xf3883ba8, 0xf3883c00, 0xf3a00000)
No shared spaces configured.

Dynamic libraries:
0x08050000 /usr/jdk/instances/jdk1.5.0/bin/java
0xfefc0000 /lib/libthread.so.1
0xfefd0000 /lib/libdl.so.1
0xfeec0000 /lib/libc.so.1
0xfea00000 /usr/jdk/instances/jdk1.5.0/jre/lib/i386/client/libjvm.so
0xfee90000 /lib/libsocket.so.1
0xfeeb0000 /usr/lib/libsched.so.1
0xfee40000 /usr/lib/libCrun.so.1
0xfee20000 /lib/libm.so.1
0xfe970000 /lib/libnsl.so.1
0xfedb0000 /lib/libm.so.2
0xfe940000 /lib/libscf.so.1
0xfed90000 /lib/libdoor.so.1
0xfe910000 /lib/libuutil.so.1
0xfe8f0000 /lib/libmd5.so.1
0xfe8d0000 /lib/libmp.so.2
0xfe8a0000 /usr/jdk/instances/jdk1.5.0/jre/lib/i386/native_threads/libhpi.so
0xfe850000 /usr/jdk/instances/jdk1.5.0/jre/lib/i386/libverify.so
0xfe3c0000 /usr/jdk/instances/jdk1.5.0/jre/lib/i386/libjava.so
0xfe810000 /usr/jdk/instances/jdk1.5.0/jre/lib/i386/libzip.so
0xeee00000 /usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.3
0xfbb60000 /usr/lib/locale/en_US.UTF-8/methods_en_US.UTF-8.so.3
0xee8f0000 /usr/jdk/instances/jdk1.5.0/jre/lib/i386/libnet.so
0xee8d0000 /usr/jdk/instances/jdk1.5.0/jre/lib/i386/libnio.so
0xee8a0000 /lib/librt.so.1
0xee880000 /lib/libaio.so.1
0xee860000 /usr/lib/libsendfile.so.1
0xee370000 /usr/jdk/instances/jdk1.5.0/jre/lib/i386/libawt.so
0xedf40000 /usr/jdk/instances/jdk1.5.0/jre/lib/i386/libmlib_image.so
0xedec0000 /usr/jdk/instances/jdk1.5.0/jre/lib/i386/motif21/libmawt.so
0xedce0000 /usr/dt/lib/libXm.so.4
0xee350000 /usr/openwin/lib/libXp.so.1
0xedc80000 /usr/openwin/lib/libXt.so.4
0xedc50000 /usr/openwin/lib/libXext.so.0
0xee330000 /usr/openwin/lib/libXtst.so.1
0xedbc0000 /usr/openwin/lib/libX11.so.4
0xedb40000 /usr/jdk/instances/jdk1.5.0/jre/lib/i386/libfontmanager.so
0xedb10000 /usr/openwin/lib/libSM.so.6
0xedaf0000 /usr/openwin/lib/libICE.so.6
0xeda80000 /usr/openwin/lib/locale/common/xlcUTF-8.so.2
0xeda60000 /usr/openwin/lib/locale/common/xomLTRTTB.so.2
0xeda40000 /usr/lib/liblayout.so.1
0xed9c0000 /usr/lib/locale/en_US.UTF-8/LO_LTYPE/en_US.UTF-8.layout.so.1
0xed980000 /usr/openwin/lib/locale/common/xiiimp.so.2
0xed960000 /usr/lib/iconv/UTF-16%UTF-8.so
0xed5c0000 /usr/lib/iconv/UTF-8%UTF-16.so
0xed5a0000 /usr/lib/im/locale/th_TH/aux.so
0xed580000 /usr/lib/im/locale/ko_KR/aux.so
0xed560000 /usr/lib/im/locale/zh_CN/aux.so
0xed530000 /usr/lib/im/locale/zh_TW/aux.so
0xed510000 /usr/lib/im/locale/ja/atokserver/atok12aux.so
0xed4e0000 /lib/libelf.so.1
0xed4c0000 /usr/lib/im/locale/zh_HK/aux.so
0xed490000 /usr/lib/iconv/UTF-8%UTF-32.so
0xed470000 /usr/lib/iconv/UTF-32%UTF-8.so

VM Arguments:
java_command: /usr/lib/patch/swupdate.jar

Environment Variables:

--------------- S Y S T E M ---------------

OS: Solaris 10 3/05 s10_74L2a X86
Copyright 2005 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 22 January 2005

uname:SunOS 5.10 Generic_118844-08 i86pc (T2 libthread)
rlimit: STACK 10240k, CORE infinity, NOFILE 65536, AS infinity
load average:0.18 0.11 0.09

CPU:total 1 family 47, cmov, cx8, fxsr, mmx, sse, sse2

Memory: 4k page, physical 1048124k(383596k free)

vm_info: Java HotSpot(TM) Client VM (1.5.0_01-b08) for solaris-x86, built on Dec 6 2004 20:59:13 by unknown with unknown Workshop:0x550

This bug can be reproduced rarely.

And received this reply:

Hi Elliott Hughes,

Thank you for this report.

We need more information to create a new Bug. In addition to
the information already given, please provide the following
details so that we can reproduce the problem ourselves:

- Complete source code of an executable test case.
To focus the investigation on what really matters, please make the
test as small as possible.
- Exact steps to run the test case.
- Expected behavior and actual behavior, including the exact text of
any output from the test case.
- Additional configuration information that may be relevant.

I was annoyed by this.

I realize that the Solaris and Java teams are separate but you'd imagine that "java_command: /usr/lib/patch/swupdate.jar" and the fact that the crash was on Solaris would have created a suspicion this might be a problem in all-Sun code.

You'd also imagine that "java_command: /usr/lib/patch/swupdate.jar" tells you how to run the test case.

You'd also imagine that a VM crash makes the "expected behavior" versus "actual behavior" question quite clear.

You'd also imagine that if I knew what "additional configuration information ... may be relevant", I'd have included it already. I mentioned that I had a core dump, but no interest was expressed in that.

But what really annoyed me was this:

We recently released J2SE 5.0 Update 5 with many bug fixes and
enhancements. Consider downloading a free copy at
http://java.sun.com/j2se/1.5.0/ and checking if the problem persists.

I experienced the crash on a fully-patched Solaris 10 system. I'd manually installed 1.5.0_05 (and various 1.6.0 builds too), but Sun doesn't try to keep my Solaris machine's Java installation up to date. And I'm not in control of what JVM Sun use to run their program when I click on their icon on the GNOME panel in their "Java Desktop System".

When I finally finish my post on my Solaris 10 experiences, I'll have a lot more to say about swupdate.jar's pathetic excuse for an automatic software update system.

I thought I couldn't get more annoyed by this "we're not even going to pass a VM crash to anyone with a clue", but I was wrong. I hadn't read the penultimate paragraph:

Since the report is likely to change significantly, please re-submit
this bug report at http://bugs.sun.com/bugdatabase/index.jsp.

It turns out that this means "we will ignore this report, and we will ignore any reply you might make".

Thank you for your help.

Sarcastic bastards.

At least Sun 6315773: Generate consumer friendly jvm hotspot crash log file (hs_err_pid*) suggests that in future hs_err_pid files will contain the URL you're supposed to submit VM crashes to. I'll try that, and see if I have any more luck.

(I like the way Solaris 10/amd64 isn't an option when selecting your OS. Maybe it's not expected to work? "Solaris x86" turns into "solaris_9", which is odd.)

[Update: the crash has since been accepted as Sun 6359201. Maybe first time round the response was from a script that noticed a bunch of fields weren't filled in, but second time round I got a human? Having filed another, different, VM crash this week, it's weird to me that the form asks you to fill in so much stuff that's already in the hs_err_pid file, as well as asking for the hs_err_pid file.]