Re: [rvm-research] Any idea about the following error ?

Hi Khaled,

Could you please tell us more about what you're trying to do, including 
why you need to use version 3.1.3, and how you got this error (e.g., are 
you running Jikes RVM 3.1.3 out of the box or have you made changes to it)?

One idea is to try Jikes RVM 3.1.4 on your system to ensure that it 
works. If it works, you could try to figure out the exact issue as Erik 
suggested. Or you could try to port your work (a patch against 3.1.3?) 
to 3.1.4.

Cheers,
Mike

On 12/01/2017 04:36 PM, Erik Brangs wrote:
> Hi,
>
> On 01.12.2017 07:30, Khaled Z Mahmoud wrote:
>> Any advice or directions on how to start tracing this error :
>>
>> JikesRVM: TROUBLE.  Got a signal (Segmentation fault; #11) from outside the VM's address space in thread 0xf72e6700.
>>
>> JikesRVM: UNRECOVERABLE trapped signal 11 (Segmentation fault)
> The phrasing "outside the VM's address space" means that this failure occurred in the native code parts, i.e. either in GNU Classpath or in the bootloader (called the bootimageRunner in 3.1.3). You could try to modifiy the compiler options for the C code (contained in the property file for your host.name in the directory build/hosts/ ), e.g. by disabling optimizations or enabling undefined behaviour sanitizers. You'd have to delete the built GNU Classpath manually because changes in the options won't be detected by the build system.
>
> You can also try to debug via log statements or print outs. It's possible that 3.1.3 has some command line options for tracing that could be useful.
>
> Unfortunately, Jikes RVM only has very rudimentary support for generating debugging symbols so you likely won't get far by trying to use gdb or the like. We've got a page about debugging in the user guide at the web site but it's very incomplete and likely not that useful for your use case.
>
> If your debugging doesn't yield anything, you could also try backporting fixes to 3.1.3. However, I couldn't tell you what fixes you'd need. The only thing for the bootloader that comes to mind and that *might* be useful is to replace calls to longjmp with uses of thread local storage. The associated git commit is 0d2d40faccd1a6421159752dc4adfbaa811bdb14 . However, that commit won't apply to 3.1.3 so you'd have to write a new patch for the 3.1.3 code. The affected 3.1.3 code is probably in sys.C and/or libvm.C.
>
>
> 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


------------------------------------------------------------------------------
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