JVM 1.4.2 crash "access violation" Tomcat

Question

Hi
We're getting nasty crashes with JVM 1.4.2_03 (other versions not yet been able to test) and cannot seem to find any log file with more information. However, I do have a DrWatson log which states among other things "access violation".
Situation: We're testing a webapplication on Tomcat (runs as a Windows service (Tomcat.exe) ). During testing the Tomcat-service suddenly ends, the Windows eventlog logs states something like: "...service ended unexpectedly..."
Environment: Tomcat 4.1.29, JDK 1.4.2_03, Windows 2000ProSP4, bi-processor Xeon machine.
While analyzing the DrWatson log file, I can always find the same important (I think) information in the same order:
- function: NtReadFile
- a bit further on: function: NtWaitForMultipleObjects
- function: NtWaitForSingleObject
- etc..
Other snippets I can also find every time are texts like these, they appear in the so called "Stack Back Trace"-sections of the drwtsn32.log:
!JVM_RegisterUnsafeMethods,
!JVM_RegisterPerfMethods,
ntdll!NtDelayExecution,
kernel32!Sleep,
!JVM_Sleep,
msafd!WSPSetSockOpt,
ws2_32!WSAAccept,
ws2_32!accept,
ws2_32!recv,
!Java_java_net_SocketInputStream_socketRead0.
If needed I can post the complete drwtsn32.log file, I only left it out because it's a bad practice to dump long texts. So if you want to take a look, please don't hesitate to ask !
The problem only seems to occur when the servermachine is completely left alone (and not logged in or in locked state) Additionally, it usually occurs after between 30-60 minutes or so. When I keep monitoring (logged in) the machine while the tests are running the crash doesn't seem to occur ?! This makes me think it could be an issue with power-saving that kicks in, like e.g. with the network-adaptor ?
If we don't use JNI, and "access violation"s are stated, does this mean it's a JVM-issue or ... ? Or is it more likely it's an issue of this Tomcat.exe ?
On a sidenote, does anyone know why a logfile might not be produced, and if there is anything i could try to make the jvm produce some intelligable output upon crashing?
Kind regards,
David

Answer 1

Hi again,
First of all thanks for the valuable help so far !
As I'm still searching an anwser for the problem, I noticed the drwtsn32.log file also (sometimes) mentions HotSpot, this is a line from my drwtsn32.log file:
mov ecx,[gHotSpotVMLongConstantEntryValueOffset+0x13f48[/i]
Now, I'm not an expert on HotSpot, but I too know there have been numerous problems reported before with this technology.
Ramesh, it sure looks like your hypothesis about the runtime compilation corresponds to this problem a lot.
Additionally, I must also mention the fact that the problem only seems to occur during stress-tests (concurrency-problem?) and is NOT reproducable reliably. All of this makes me think even more that it's a JVM problem of some kind, what is your (anyone) opinion about this ?
Again, thanks for your support, it sure helps a lot !
Kind regards,
David