I tried to investigate the sensitivity of crashes probability on the eden size and there is definitely some. In my testing setup, if the eden size was set around 2 MB, it crashed. For values around 1MB or 10 MB, there were no crashes or were significantly less probable. However, there seems to be no strict limit.
-- Pavel
st 20. 11. 2019 v 12:59 odesílatel Alistair Grant notifications@github.com napsal:
Hi Eliot,
Tracing back from the first time a warning is printed in the assert VM, it looks like what is happening is that a BlockClosure in the currently executing context is being moved during garbage collection, but that the FP isn't being updated.
I have a script which walks gdb to the point where the FP corruption occurs, but ignoring the multiple steps it takes to get to the correct iteration:
Setting a breakpoint in scavengeReferentsOf() at line 42259 in gcc3x-cointerp.c and then:
(gdb) list 42254 if (oopisGreaterThanOrEqualToandLessThan(referent, ((futureSpace()).start), futureSurvivorStart())) { 42255 newLocation = referent; 42256 foundNewReferentOrIsWeakling = 1; 42257 } 42258 else { 42259 newLocation = copyAndForward(referent); 42260 if (((newLocation & (tagMask())) == 0) 42261 && (oopisLessThan(newLocation, GIV(newSpaceLimit)))) { 42262 foundNewReferentOrIsWeakling = 1; 42263 } (gdb) call printCallStack() 0x7ffffffe3f70 I SessionManager>launchSnapshot:andQuit: 0x1508860: a(n) SessionManager 0x7ffffffe3fe0 I [] in SessionManager>snapshot:andQuit: 0x1508860: a(n) SessionManager 0x7ffffffe4020 I [] in BlockClosure>newProcess 0x118a728: a(n) BlockClosure
(gdb) n (gdb) call printCallStack() 0x7ffffffe3f70 I SessionManager>launchSnapshot:andQuit: 0x1508860: a(n) SessionManager 0x7ffffffe3fe0 I [] in SessionManager>snapshot:andQuit: 0x1508860: a(n) SessionManager 0x7ffffffe4020 I [] in INVALID RECEIVER>newProcess 0x118a728 0x118a728 is a forwarded object to 0x488fca0 of slot size 7 hdr8 .....
Setting a breakpoint at line 46909:
(gdb) list 46904 /* begin initFutureSpaceStart */ 46905 oldStart = GIV(futureSurvivorStart); 46906 GIV(futureSurvivorStart) = (GIV(futureSpace).start); 46907 GIV(pastSpaceStart) = oldStart; 46908 assert(oopisGreaterThanOrEqualToandLessThanOrEqualTo(GIV(pastSpaceStart), ((pastSpace()).start), ((pastSpace()).limit))); 46909 GIV(freeStart) = ((eden()).start); 46910 /* begin initSpaceForAllocationCheck:limit: */ 46911 aNewSpace = (&(eden())); 46912 if (!(GIV(memory) == null)) { 46913 if (checkAllocFiller()) { (gdb) call printCallStack() 0x7ffffffe3f70 I SessionManager>launchSnapshot:andQuit: 0x1508860: a(n) SessionManager 0x7ffffffe3fe0 I [] in SessionManager>snapshot:andQuit: 0x1508860: a(n) SessionManager 0x7ffffffe4020 I [] in INVALID RECEIVER>newProcess 0x118a728 0x118a728 is a forwarded object to 0x488fca0 of slot size 7 hdr8 ..... (gdb) n 46911 aNewSpace = (&(eden())); (gdb) call printCallStack() 0x7ffffffe3f70 I SessionManager>launchSnapshot:andQuit: 0x1508860: a(n) SessionManager 0x7ffffffe3fe0 I [] in SessionManager>snapshot:andQuit: 0x1508860: a(n) SessionManager 0x7ffffffe4020 I [] in INVALID RECEIVER>newProcess 0x118a728 is in new space (gdb)
The VM actually crashes some time later, however the call stack shows the an invalid receiver.
Shouldn't the FP be updated to point to the moved BlockClosure?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/444?email_source=notifications&email_token=AIJPEW2MHBCK5I4WIDZKV2LQUURAZA5CNFSM4JNBNJH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEERXY4Y#issuecomment-555973747, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIJPEW3CYFSVOHIYMERMOXLQUURAZANCNFSM4JNBNJHQ .