JVM Crash with no hs file or information whatsoever - and how to trace?

Question

Hi
We have a frustrating problem with jvm 1.4.2_04 (and we've also tried 1.4.2_06). We're getting crashes of the jvm (access violations), which do not result in a hotspot log file, and so its very difficult to track down what's going on. They happen at random times and I cannot spot anything obvious at atll from the our application logs. We have found it generates Dr Watson output (i've copied at the end) but I really don't know how to interpret this.
Does anyone know why a hotspot file might not be produced, and if is anything i could try to make the jvm produce some intelligable output upon crashing?
Thanks very much,
Steve
----> State Dump for Thread Id 0xad0 <----
eax=1a87b588 ebx=00140d72 ecx=1a72e7d9 edx=00000000 esi=06c5fe84 edi=06c5fe20
eip=08053665 esp=06c5fe10 ebp=06c5fe44 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
function: jvm
0805364a 8b4e14 mov ecx,[esi+0x14]
0805364d 83793800 cmp dword ptr [ecx+0x38],0x0
08053651 7421 jz jvm+0x53674 (08053674)
08053653 e860090000 call jvm+0x53fb8 (08053fb8)
08053658 8b4804 mov ecx,[eax+0x4]
0805365b 8d7ddc lea edi,[ebp-0x24]
0805365e 83c108 add ecx,0x8
08053661 57 push edi
08053662 50 push eax
08053663 8b11 mov edx,[ecx]
FAULT ->08053665 ff92bc000000 call dword ptr [edx+0xbc] ds:0023:000000bc=????????
0805366b 8bce mov ecx,esi
0805366d e808000000 call jvm+0x5367a (0805367a)
08053672 ebd6 jmp jvm+0x5364a (0805364a)
08053674 5f pop edi
08053675 5e pop esi
08053676 c9 leave
08053677 c20400 ret 0x4
0805367a 33c0 xor eax,eax
0805367c 390584781108 cmp [jvm!gHotSpotVMLongConstantEntryValueOffset+0x72dc (08117884)],eax
08053682 7e12 jle jvm+0x53696 (08053696)

Answer 1

First of all, I'm not at all surprised that there isn't a hotspot log file to be found. Acces Exceptions in Windows applications (I'm assuming from your post that you are executing the jvm under windows), are roughly equivalent to NullPointerExceptions in the Java language.
More specifically, the represent 'unexpected' flows of code execution, since they signal that the program tried to acces a variable which did not excist according to windows. Just as with NullPointerExceptions, this generally indicates that it never occured to the programmer that his reference/variable might not be valid anymore.
Therefore, there will probably not be a 'catching' block, that makes sure that the log-stream is flushed before the jvm terminates. Recall that in java, you would also need to do this by hand if you're to ensure that logging happens correctly.
As for any resolutions to the problem, I can only suggest submitting it to Sun as an 'official' JVM bug...