Re: [rvm-research] Tracing Segmentation Fault in Jikes

Hi,

On 13.12.2017 08:48, Khaled Z Mahmoud wrote:
> *Here is the Summary of what Is Printed*:
> JikesRVM: hardwareTrapHandler SignalNO:11  Context:0x58498c8c - InsPtr:0xf7581d57 instFollowPtr:0xffffffff threadPtr:(nil) jtocPtr:0x600802e0

Have you added any new instructions to the Jikes RVM assemblers? instFollowPtr is computed by the bootloader. The bootloader should be able to compute instFollowPtr (using getInstructionFollowing from sysSignal_ia32.c) for all code emitted by the Jikes RVM compilers. The Jikes RVM doesn't ship with an IA32 disassembler, so you'll have to modify sysSignal_ia32.c when adding new instructions.

If you haven't added any new instructions, you can be sure that the failure occurs in code not generated by Jikes RVM's compilers (otherwise the instFollowPtr would have been computed).
 
>  1. *How do I know which line or function either in C or in Java caused this error ?*

As I mentioned before, support for debugging symbols in Jikes RVM is mostly non-existent. You can get debugging symbols for methods in the boot image for baseline-compiler-only images but in my experiences that's not helpful enough. You can try to narrow down the failing methods by inserting print outs in the VM or in the class library.

>  2. *Suppose I explicitly added code to the Jikes to make an array out of bound exception ? Like int[]  xs = new int[10];. x[100]++. Since, the Jikes itself is not running JVM (It is the JVM itself), the previous code at the Jikes core could result in segmentation fault and a trap ?*

The trap information would be passed back into Java (into RuntimeEntrypoints.deliverHardwareException(..)). If the trap occurred in uninterruptible code, you would get a crash. In interruptible code (even in the VM), this would result in an ArrayIndexOutOfBoundsException.

> I am now tracing a segmentation fault in Jikes. This happens directly after I invoke Jikes and most likely in the boot process. The signal number 11. OS seems to send a signal to the C code at ./tools/bootloader/sysSignal.c
> 
> Yes, there are modifications to the Jikes source and are mostly the Java code

If the failures don't occur in an unmodified VM, you could try to disable the new code step by step until the failure disappears.

You could also try to reason about the modifications. When the VM boots, subsystems are enabled in a certain order. If your modifications cause a subsystem to be required before it's actually ready, you would get crashes (e.g. trying to allocate before allocation is enabled). You can take a look at VM.boot() and VM.finishBooting() for details. You would also get crashes or problems when you're doing instrumentation and the set of instrumentated methods isn't correctly defined (e.g. instrumentation of methods used in the implementation of the instrumentation).

You can also rebuild all the native code without optimizations: modify the appropriate properties in the build/hosts directory, do a clean and throw away the component directory for GNU classpath and rebuild.

Lastly, it is always possible that your modifications are breaking some assumptions that haven't been made explicit in the current version of Jikes RVM. For explicit assumptions, you can make sure to build with a diverse set of configurations (e.g. prototype, prototype-opt, development, ExtremeAssertions*YourGC*) to catch a few problems.


Kind regards,

Erik Brangs

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jikesrvm-researchers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers