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 (methodOOP=methodOOP@entry=0x4093d4a0) at xlat.c:3889 3889 if (methodOOP->flags & F_XLAT_DISCARDED) (gdb) bt #0 _gst_release_native_code (methodOOP=methodOOP@entry=0x4093d4a0) 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, p_oop=p_oop@entry=0xbfffea74) 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 _______________________________________________ help-smalltalk mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-smalltalk
