Details
Description
Currently any unhandled signals and memory faults terminate the VM with an unknown error. Whilst correct, it could be more useful for debugging if these faults were turned into a Jikes RVM virtual machine error and these virtual machine errors had access to the context when the fault occurred.
In more detail our existing scheme is:
1) get signal
2) trap into libvm.C hardware signal hander
3) decipher signal, if the VM processor address is bad die, if the stack frame address in the VM_Processor is bad die, set context up for entry into VM_Runtime.deliverHardwareException
4) determine in VM_Runtime.delieverHardwareException if this is a known or unknown exception and then deliver that exception
5) for unknown errors no signal handler will be found so we dump the stack and leave the VM
(NB it looks like we're not respecting thread uncaught exception handler properly in the VM_Runtime code)
This proposal is to implement Jikes RVM specific virtual machine error and unknown error classes in java.lang, for these objects to carry the context that caused their fault and for this to be printed if they are uncaught. This same context information could be accessed via JikesRVMSupport function to support code that wants to catch and debug virtual machine errors properly.
Issue Links
- relates to
-
RVM-79
Dump all registers on a fault on Intel
-
The thing to be careful of is to make sure that recursive failures don't hang the VM. At some point we need to give up and exit quickly and with a 100% chance of success. (If the VM is really hosed, then trying to do anything to raise a "real" exception/error will result in a new crash sequence and we never get anywhere).
We can probably do better than we currently are, but we do need a way out when things go horribly wrong.