Help
A known example is access violation that occurs when reading/writing memory at an address to which no memory page was mapped or transferring control to such a region. If a JET-compiled application runs into the problem, the Runtime prints TRAP#3 message and execution abnormally terminates.
Of course, it should never happen in a pure Java application but, unfortunately, it may happen due to:
- bugs in the native method libraries used by the application
- JNI misuses (correct usage of JNI is tricky for inexperienced programmers)
- operating system malfunction (yes, we found a few examples when debugging)
- bugs in the JET Optimizer or Runtime (despite it?s a rare case for the matured versions released last years, we must be honest with you 8) )
Often, the errors are volatile, that is, hardly reproducible. I recall a support case when an Excelsior JET customer received reports about an unrecoverable error from his customers but he could not reproduce it in his test environment. Of course, he was not able to provide Excelsior Support with a sample on which the problem appeared. After many trilas we finally managed to find the root cause but it was double tough.
To address the problem, we scheduled implementing a special diagnostic facility in Excelsior JET 6.5. If an unrecoverable error occurs, the JET Runtime collects various information about the application state, logs it into a file, and prints the error message referencing that file. We believe this feature will enable us to reveal the root cause of the errors faster and easier and help our customers.
The diagnostic logging has been already implemented and is available in Excelsior JET 6.5 beta 4.
