Re: [Help-smalltalk] JIT crashes due non-executable memory

[Holger Hans Peter Freyther]

On Sun, Jun 09, 2013 at 07:34:05PM +0200, Holger Hans Peter Freyther wrote:
> On Sun, Jun 09, 2013 at 02:58:33PM +0200, Holger Hans Peter Freyther wrote:
> 
> > this should already walk over the ctx->method and mark it. I need to
> > look deeper into the marking and see which xlated method is swept
> 
> And I am back to memory corruption as a cause of this. In theory valgrind
> could work for GST but I don't know where to start. :}

Hardware watchpoint 1: -location $1->flags

Old value = 5243174
New value = 1048870
_gst_release_native_code (address@hidden) at xlat.c:3889
3889      if (methodOOP->flags & F_XLAT_DISCARDED)
(gdb) bt
#0  _gst_release_native_code (address@hidden) at xlat.c:3889
#1  0xb7f2c8a0 in maybe_release_xlat (oop=0x4093d4a0) at oop.inl:165
#2  alloc_oop (flags=262144, objData=0xb760e4ac) at oop.inl:188
#3  _gst_alloc_obj (size=20, address@hidden) at oop.c:787
#4  0xb7f73788 in new_instance (p_oop=0xbfffea74, class_oop=0x408f44a8) at 
dict.inl:710
#5  _gst_make_block_closure (blockOOP=0x40910a88) at interp.c:1303
#6  0x081e9dd5 in ?? ()

so the idea is that if F_XLAT_REACHABLE is set the entire "maybe_release_xlat"
will trigger... I was disabling the call from alloc_oop. Do you remember why
the call is inside the alloc_oop at all (and the others)? E.g. why is it too
late in the "oop swept" routine? The jitted code is 'attached' to the method
OOP anyway?

holger