<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Nicolas,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 3, 2019 at 1:10 PM Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I confirm that each crash follows a SIGIO -> forceInterruptCheck() with corrupted stack pointer pointing to methodZone (that is executable zone so program counter).</div><div>I did:</div><div>1) remove static declaration of methodZoneBase and limitAddress in cogitX64Sysv.c so as to make them exported globals</div><div>2) declared them as extern sqInt in gcc-cointerp.c</div><div>3) instrumented forceInterruptCheck() so as to emit a warning and/or set a breakpoint:</div><div><br></div><div> if ( getsp() > methodZoneBase && getsp() <= limitAddress ) {<br> printf("pb in forceInterruptCheck\n");<br> }</div><div><br></div><div>Unlike what I said, forceInterruptCheck() does nothing special and certainly not invoke Smalltalk code nor JITTED code.</div><div>The interruptCheckChain function that it could invoke is generally null (except for debug/simulation purpose), and always null in the crash i observed.</div><div>The signal handler also generally operate on same stack (unless specifically asked via sigaction() - which is not the case).</div><div>My earler diagnostic was driven by the false assumption that handler would use the interrupt stack pointer (IST), and thus that only special stack pointer manipulation happening in trampoline could corrupt it, hmmm that was late night blurred minded ;)<br></div><div><br></div><div>What comes to my mind:</div><div>- the signal SIGIO might happen while we are manipulating the stack pointer, hence the heisenbug<br></div><div>- the stack pointer could be offseted by some incorrect code (but why no error would happen before SIGIO then?)</div><div><br></div><div>I don't have clear understanding of all spur machinery details that would help further diagnosis</div><div>Eliot, doesn't it sound interesting?<br></div></div></blockquote><div><br></div><div>It looks to me like the right cause. The corruption I was seeing in the methodSZOne doesn't;t look like a bug in the JIT; it looks like overwriting. I had thought we were using sigaltstack to ensure the signal handler runs on a dedicated stack, but it appears we don't. If I'm right that we're not using sigaltstack then this may be very easy to fix :-)</div><div><br></div><div>[I have to mention ALSA and its awful SIGIO sign al handling code; see platforms/unix//vm-sound-ALSA/sqUnixSoundALSA.c. I don't think this affects the Mac, but it could be an issue on Linux]</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 3 oct. 2019 à 08:10, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Maybe I draw conclusions too quickly.</div><div>But clearly, the signal handler has a stack pointer pointing in methodZone.</div><div><br></div><div>(lldb) p/x $rsp<br>(unsigned long) $211 = 0x0000000107c92da0</div><div>(lldb) p/x methodZoneBase<br>(sqInt) $212 = 0x0000000107c01d30</div><div>(lldb) p/x limitAddress<br>(usqInt) $213 = 0x0000000107d5e000</div><div><br></div><div>It remains to see how that happened.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 3 oct. 2019 à 05:49, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi all,</div><div>So I finally got it!</div><div>That's our specific handling of SIGIO with forceInterruptCheck.<br></div><div>Don't you JIT the signal handler!</div><div><br></div><div>The signal handler is using a different stack pointer so as to not interfere with the program.</div><div>Until Cog decide to jump into JITTED code from within the signal handler.</div><div>It now share a stack pointer pointing somewhere in cog methodZone, and anything it does with it's stack (call a function, save registers...) will destroy the JITTED code.</div><div>It even happened when I used the debugger which shares the interrupt handler stack pointer!</div><div><br></div><div>Why does it not happen in linux, and why only Mac OS 64, I have no clue...</div><div>But we can't decently live very long with such handling.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 2 oct. 2019 à 23:29, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Eliot,</div><div>so I have set watchpoint to 4 previous crash and got this:</div><div><br></div><div>(lldb) run ../../image/crash.image<br>There is a running process, kill it and restart?: [Y/n] <br>Process 98150 exited with status = 9 (0x00000009) <br>Process 98164 launched: '/Users/nicolas/Smalltalk/OpenSmalltalk/opensmalltalk-vm/build.macos64x64/squeak.cog.spur/SqueakDebug.app/Contents/MacOS/Squeak' (x86_64)<br>Process 98164 stopped<br>* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1<br> frame #0: 0x00000001001618ec Squeak`-[sqSqueakMainApplication setupMenus](self=0x000000010076e1a0, _cmd="setupMenus") at sqSqueakMainApplication.m:123<br> 120 <br> 121 - (void) setupMenus {<br> 122 // nothing to do so far since the menu is setup in the MainMenu.nib file<br>-> 123 }<br> 124 <br> 125 - (void) setupTimers {<br> 126 extern void SetUpTimers(void);<br>Target 0: (Squeak) stopped.<br>(lldb) wa se e -s 1 -- 0x107c992b4<br>Watchpoint created: Watchpoint 35: addr = 0x107c992b4 size = 1 state = enabled type = w<br>(lldb) wa se e -s 1 -- 0x107c929e0<br>Watchpoint created: Watchpoint 34: addr = 0x107c929e0 size = 1 state = enabled type = w<br>(lldb) wa se e -s 1 -- 0x0000000107c945df<br>Watchpoint created: Watchpoint 36: addr = 0x107c945df size = 1 state = enabled type = w<br>(lldb) wa se e -s 1 -- 0x0000000107c92da3<br>Watchpoint created: Watchpoint 37: addr = 0x107c92da3 size = 1 state = enabled type = w<br> new value: -3689348814741910324<br>(lldb) c<br>Process 98164 resuming<br><br>Watchpoint 34 hit:<br>new value: -3689348814741910456<br>Process 98164 stopped<br>* thread #1, queue = 'com.apple.main-thread', stop reason = watchpoint 34<br> frame #0: 0x0000000100102067 Squeak`byteAtPointerput(ptr="H???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????, val=72) at sqMemoryAccess.h:136<br> 133 /* Use static inline functions when the compiler produces efficient code for small accessors.<br> 134 These are preferred because static type checking will prevent inadvertent confusion of pointers and oops. */<br> 135 static inline sqInt byteAtPointer(char *ptr) { return (sqInt)(*((unsigned char *)ptr)); }<br>-> 136 static inline sqInt byteAtPointerput(char *ptr, int val) { return (sqInt)(*((unsigned char *)ptr)= (unsigned char)val); }<br> 137 static inline sqInt shortAtPointer(char *ptr) { return (sqInt)(*((short *)ptr)); }<br> 138 static inline sqInt shortAtPointerput(char *ptr, int val) { return (sqInt)(*((short *)ptr)= (short)val); }<br> 139 static inline sqInt intAtPointer(char *ptr) { return (sqInt)(*((int *)ptr)); }<br>Target 0: (Squeak) stopped.<br>(lldb) <br>Process 98164 resuming<br><br>Watchpoint 37 hit:<br>old value: -3689348814741910324<br>new value: -3689912642157150198<br>Process 98164 stopped<br>* thread #1, queue = 'com.apple.main-thread', stop reason = watchpoint 37<br> frame #0: 0x000000010012de84 Squeak`fillInMethodHeadersizeselector(method=0x0000000107c92da0, size=1240, selector=4435376352) at cogitX64SysV.c:6321<br> 6318 <br> 6319 (method->cmType = CMMethod);<br> 6320 (method->objectHeader = nullHeaderForMachineCodeMethod());<br>-> 6321 (method->blockSize = size);<br> 6322 (method->methodObject = methodObj);<br> 6323 <br> 6324 /* If the method has already been cogged (e.g. Newspeak accessors) then<br>Target 0: (Squeak) stopped.<br>(lldb) <br>Process 98164 resuming<br><br>Watchpoint 36 hit:<br>new value: -3689348814741910520<br>Process 98164 stopped<br>* thread #1, queue = 'com.apple.main-thread', stop reason = watchpoint 36<br> frame #0: 0x0000000100102067 Squeak`byteAtPointerput(ptr="\b???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????, val=8) at sqMemoryAccess.h:136<br> 133 /* Use static inline functions when the compiler produces efficient code for small accessors.<br> 134 These are preferred because static type checking will prevent inadvertent confusion of pointers and oops. */<br> 135 static inline sqInt byteAtPointer(char *ptr) { return (sqInt)(*((unsigned char *)ptr)); }<br>-> 136 static inline sqInt byteAtPointerput(char *ptr, int val) { return (sqInt)(*((unsigned char *)ptr)= (unsigned char)val); }<br> 137 static inline sqInt shortAtPointer(char *ptr) { return (sqInt)(*((short *)ptr)); }<br> 138 static inline sqInt shortAtPointerput(char *ptr, int val) { return (sqInt)(*((short *)ptr)= (short)val); }<br> 139 static inline sqInt intAtPointer(char *ptr) { return (sqInt)(*((int *)ptr)); }<br>Target 0: (Squeak) stopped.<br>(lldb) <br>Process 98164 resuming<br><br>Watchpoint 35 hit:<br>new value: -3689348814741910456<br>Process 98164 stopped<br>* thread #1, queue = 'com.apple.main-thread', stop reason = watchpoint 35<br> frame #0: 0x0000000100102067 Squeak`byteAtPointerput(ptr="H???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????, val=72) at sqMemoryAccess.h:136<br> 133 /* Use static inline functions when the compiler produces efficient code for small accessors.<br> 134 These are preferred because static type checking will prevent inadvertent confusion of pointers and oops. */<br> 135 static inline sqInt byteAtPointer(char *ptr) { return (sqInt)(*((unsigned char *)ptr)); }<br>-> 136 static inline sqInt byteAtPointerput(char *ptr, int val) { return (sqInt)(*((unsigned char *)ptr)= (unsigned char)val); }<br> 137 static inline sqInt shortAtPointer(char *ptr) { return (sqInt)(*((short *)ptr)); }<br> 138 static inline sqInt shortAtPointerput(char *ptr, int val) { return (sqInt)(*((short *)ptr)= (short)val); }<br> 139 static inline sqInt intAtPointer(char *ptr) { return (sqInt)(*((int *)ptr)); }<br>Target 0: (Squeak) stopped.<br>(lldb) <br>Process 98164 resuming<br><br>Watchpoint 37 hit:<br>old value: -3689912642157150198<br>new value: -5066732099722018553<br>Process 98164 stopped<br>* thread #1, queue = 'com.apple.main-thread', stop reason = watchpoint 37<br> frame #0: 0x000000010002e801 Squeak`forceInterruptCheck at gcc3x-cointerp.c:64151<br> 64148 /* StackInterpreter>>#forceInterruptCheck */<br> 64149 sqInt<br> 64150 forceInterruptCheck(void)<br>-> 64151 { DECL_MAYBE_SQ_GLOBAL_STRUCT<br> 64152 void (*iccFunc)();<br> 64153 StackPage *thePage;<br> 64154 <br>Target 0: (Squeak) stopped.<br>(lldb) bt<br>* thread #1, queue = 'com.apple.main-thread', stop reason = watchpoint 37<br> * frame #0: 0x000000010002e801 Squeak`forceInterruptCheck at gcc3x-cointerp.c:64151<br> frame #1: 0x00007fff6ab9af5a libsystem_platform.dylib`_sigtramp + 26<br> frame #2: 0x0000000107c10699<br> frame #3: 0x0000000107c9646f<br> frame #4: 0x0000000107c9633e<br> frame #5: 0x0000000107c962ac<br> frame #6: 0x0000000107c961e9<br> frame #7: 0x0000000107c8fcf8<br> frame #8: 0x0000000107c98605<br> frame #9: 0x0000000107c8bbfe<br> frame #10: 0x0000000107c1100e<br> frame #11: 0x0000000107c8c4ad<br> frame #12: 0x0000000107c0cef6<br> frame #13: 0x0000000107c8c2a5<br> frame #14: 0x0000000107c8bb4c<br> frame #15: 0x0000000107c0cef6<br> frame #16: 0x0000000107c8ba05<br> frame #17: 0x0000000107c8b85b<br> frame #18: 0x0000000107c1100e<br> frame #19: 0x0000000107c8b7e1<br> frame #20: 0x0000000107c57018<br> frame #21: 0x0000000107c018c8<br>(lldb) call printCallStack()<br><br>Watchpoint 34 hit:<br>old value: -3689348814741910456<br>new value: 4435376368<br>error: Execution was interrupted, reason: watchpoint 34.<br>The process has been returned to the state before expression evaluation.<br>(lldb) call printCogMethodFor((void*)0x0000000107c10699)<br><br>Watchpoint 34 hit:<br>old value: 4435376368<br>new value: 0<br>error: Execution was interrupted, reason: watchpoint 34.<br>The process has been returned to the state before expression evaluation.</div><div><br></div><div>I don't know how to proceed, but maybe there's enough clue for you...<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 30 sept. 2019 à 01:28, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Nicolas,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 25, 2019 at 12:32 AM Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div>I noticed that many crash happen in testSendTimeout.</div><div>This test is organizing a race:</div><div>- Smalltalk fill the socket send buffer</div><div>- the OS tries to drain</div><div><br></div><div>The other thing I noticed is that <font face="verdana,sans-serif">[</font>SocketTest suite run] takes 7 to 8s on macos while only 2 to 3s on ubuntu and windows</div><div>So it might be that some test times out on macos, while it doesn't on other OS.</div><div><br></div><div>This would explain that many crash also happen in JITted Timer loop, and that we cannot observe it in other OSes.</div></div></blockquote><div><br></div><div>Yes, that is, I think, an important clue. The other one is that, given that the crash always happens only early in a run, plus the address at which it crashes in machine code, suggests to me that the crash occurs when the interpreter invokes a block in the JITted startTimerLoop.</div><div><br></div><div>What worries me is that the JITted code for startTimerLoop looks completely corrupted, not merely moved or overwritten (the method header looks OK up to the selector field, which is the last field in the header). So I'm wondering whether it could be a bug in support code overwriting machine code, and hence that not might be related to a 32-bit vs 64-bit code issue. I was hoping your recent sqUnixSocket.c changes might work but I'm sure they have no bearing.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The access to OS ressources and the race may also explain some randomization of the crash...<br></div><div><br></div><div>So one idea would be to make the test timeout in linux too, see if we can make it crash then try using rr.</div><div>Maybe it's possible with a huge Socket buffer, a smaller image side buffer (we could reduce the size from 1000 to 1 so as to increase overhead).</div></div></blockquote><div><br></div><div>Yes, that's a good idea. But I do think we need to set up a reliable remote server, som thing that acts like an infinite sink for receiving a par4ticular large Monticello package, so that ev very time the example runs the same package is indeed copied to a remote server. Would it be possible to construct such a fake Monticello server? </div><div><br></div><div>What I'm wanting the server to do is</div><div>a) take a while to respond to the Monticello package contents request</div><div>b) to never include a particular package which the example would always try and upload</div><div><br></div><div>The test case would be to copy a particular version of VMMaker from package-cache to the remote "fake" server</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>It's just theories I tried to construct while biking, not in front of a keyboard, and I won't be able to verify until this evening...</div><div>But the watchpoint strategy is too much vain shooting in the dark, we need more ellaborated plans ;)<br></div></div></blockquote><div><br></div><div>Does anyone see the crash on macOS in 32 bits?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Le mar. 24 sept. 2019 à 00:28, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 24 sept. 2019 à 00:25, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Follow up: so we have a problem of repeatability...</div><div>I found nothing like rr for macos, and CPU watchpoint capability is too restricted to be usefull.</div><div><br></div><div>So what I did is save a crash.image attempting to crash at resumption time:</div><div> Smalltalk saveAs: 'crash'.<br> Smalltalk snapshot: true andQuit: true.<br> 5 timesRepeat: [SocketTest suite run].<br></div><div><br></div><div>Then I launched the vm under lldb and gathered $pc stats to see if I could observe some reproducibility</div><div>(lldb) p/x $pc - methodZoneBase<br>0x00000000000a0e94<br>0x0000000000090f70<br>0x000000000009f824<br>0x000000000009bfc8<br>0x000000000009d030<br>0x000000000009c7c0<br>0x00000000000951e0<br>0x00000000000949c8 <- once<br>0x0000000000094418<br>0x00000000000949c8 <— twice<br>0x000000000009b848<br>0x00000000000a0e94 <- twice<br>0x000000000009a176<br>0x000000006dfff2e0 ???<br>0x00000000000996d1<br>0x00000000000949c8 <- thrice good candidate for watchpoint set<br>0x000000000009ae70<br>0x000000000009ae70<br>0x00000000000a18e7<br>0x0000000000095470<br>0x000000000009c458<br>0x00000000000a0a7c<br>0x0000000000093e89<br>0x000000000009beb0<br>0x0000000000095a37<br>0x0000000000095408<br>0x00000000000a06bc<br>0x000000000009cd48<br>0x0000000000095408 <- twice<br>0x000000000009ba41<br>0x0000000000095408 <- thrice new candidate for watchpoint set<br>0x0000000000045258 <— smallest ever<br>0x000000000009c7c0<br>0x0000000000095408 <- fourth ! the watch point was set here, why didn’t it stop??? argh methodZoneBase was incremented after I set the watchpoint!!!<br>0x00000000000a12dc<br>0x00000000000951e0<br>0x00000000000a0e24<br>0x000000000009ff8c<br>0x000000000009c7f6<br>0x000000000009a626</div><div><br></div><div>Then I have chosen to watch the most frequent crash address,</div><div>that is methodZoneBase+0x0000000000095408,</div><div>Unfortunately, s commented above, I missed one (I set the watchpoint too early, before methodZoneBase took its definitive address).</div><div><br></div><div> And after a few (a bunch of) trials, here is what I found:</div><div><br></div><div>(lldb) run ../../image/crash.image<br>There is a running process, kill it and restart?: [Y/n] <br>Process 28175 exited with status = 9 (0x00000009) <br>Process 28185 launched: '/Users/nicolas/Smalltalk/OpenSmalltalk/opensmalltalk-vm/build.macos64x64/squeak.cog.spur/Squeak.app/Contents/MacOS/Squeak' (x86_64)<br>Squeak was compiled with optimization - stepping may behave oddly; variables may not be available.<br>Process 28185 stopped<br>* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 6.1<br> frame #0: 0x000000010007bc22 Squeak`-[sqSqueakOSXApplication doHeadlessSetup](self=0x000000010066fc00, _cmd="doHeadlessSetup") at sqSqueakOSXApplication.m:125 [opt]<br> 122 //No super call here as we've already set headless from command line or info.plist<br> 123 extern BOOL gSqueakHeadless; <br> 124 // Notice that setActivationPolicy: is available in OSX 10.6 and later<br>-> 125 if ([NSApp respondsToSelector:@selector(setActivationPolicy:)]) {<br> 126 if (gSqueakHeadless) {<br> 127 [NSApp setActivationPolicy:NSApplicationActivationPolicyProhibited];<br> 128 } else {<br>Target 0: (Squeak) stopped.<br>(lldb) wa s e -s 1 -- methodZoneBase+0x0000000000095408<br>Watchpoint created: Watchpoint 33: addr = 0x107c58138 size = 1 state = enabled type = w<br> new value: -3689348814741910324<br>(lldb) cont<br>Process 28185 resuming<br><br>Watchpoint 33 hit:<br>old value: -3689348814741910324<br>new value: -3689348814741910836<br>Process 28185 stopped<br>* thread #1, queue = 'com.apple.main-thread', stop reason = watchpoint 33<br> frame #0: 0x00000001000731dc Squeak`fillInMethodHeadersizeselector(method=0x0000000107c58130, size=544, selector=4435118304) at cogitX64SysV.c:6320 [opt]<br> 6317 sqInt rawHeader;<br> 6318 <br> 6319 (method->cmType = CMMethod);<br>-> 6320 (method->objectHeader = nullHeaderForMachineCodeMethod());<br> 6321 (method->blockSize = size);<br> 6322 (method->methodObject = methodObj);<br> 6323 <br>Target 0: (Squeak) stopped.<br>(lldb) <br>Process 28185 resuming<br><br>Watchpoint 33 hit:<br>old value: -3689348814741910836<br>new value: -3689571654825360894<br>Process 28185 stopped<br>* thread #1, queue = 'com.apple.main-thread', stop reason = watchpoint 33<br> frame #0: 0x0000000100073255 Squeak`fillInMethodHeadersizeselector(method=0x0000000107c58130, size=544, selector=4435118304) at cogitX64SysV.c:6339 [opt]<br> 6336 (method->selector = selector);<br> 6337 (method->cmNumArgs = argumentCountOfMethodHeader(methodHeader));<br> 6338 (method->cmHasMovableLiteral = hasMovableLiteral);<br>-> 6339 if ((method->cmRefersToYoung = hasYoungReferent)) {<br> 6340 addToYoungReferrers(method);<br> 6341 }<br> 6342 (method->cmUsageCount = initialMethodUsageCount());<br>Target 0: (Squeak) stopped.<br>(lldb) bt<br>* thread #1, queue = 'com.apple.main-thread', stop reason = watchpoint 33<br> * frame #0: 0x0000000100073255 Squeak`fillInMethodHeadersizeselector(method=0x0000000107c58130, size=544, selector=4435118304) at cogitX64SysV.c:6339 [opt]<br> frame #1: 0x000000010004f90c Squeak`compileCogMethod [inlined] generateCogMethod(selector=<unavailable>) at cogitX64SysV.c:7098 [opt]<br> frame #2: 0x000000010004f7a5 Squeak`compileCogMethod(selector=4435118304) at cogitX64SysV.c:27780 [opt]<br> frame #3: 0x000000010004bc54 Squeak`cogselector(aMethodObj=4468481712, aSelectorOop=4435118304) at cogitX64SysV.c:4833 [opt]<br> frame #4: 0x0000000100013d4d Squeak`primitiveClosureValue at gcc3x-cointerp.c:27237 [opt]<br> frame #5: 0x0000000107bd1925<br> frame #6: 0x000000010000236b Squeak`interpret at gcc3x-cointerp.c:2767 [opt]<br> frame #7: 0x000000010008ed55 Squeak`-[sqSqueakMainApplication runSqueak](self=0x000000010066fc00, _cmd=<unavailable>) at sqSqueakMainApplication.m:201 [opt]<br> frame #8: 0x00007fff44b077b8 Foundation`__NSFirePerformWithOrder + 360<br> frame #9: 0x00007fff4297cf57 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23<br> frame #10: 0x00007fff4297ce7f CoreFoundation`__CFRunLoopDoObservers + 527<br> frame #11: 0x00007fff4295f3f8 CoreFoundation`__CFRunLoopRun + 1240<br> frame #12: 0x00007fff4295ec93 CoreFoundation`CFRunLoopRunSpecific + 483<br> frame #13: 0x00007fff41c49d96 HIToolbox`RunCurrentEventLoopInMode + 286<br> frame #14: 0x00007fff41c49a0f HIToolbox`ReceiveNextEventCommon + 366<br> frame #15: 0x00007fff41c49884 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 64<br> frame #16: 0x00007fff3fef9a73 AppKit`_DPSNextEvent + 2085<br> frame #17: 0x00007fff4068fe34 AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044<br> frame #18: 0x00007fff3feee885 AppKit`-[NSApplication run] + 764<br> frame #19: 0x00007fff3febda72 AppKit`NSApplicationMain + 804<br> frame #20: 0x00007fff6a88c015 libdyld.dylib`start + 1<br>(lldb) <br></div><div><br></div><div>Here I don't know how to proceed, because I have no knowledge of this part of the VM, it's also quite late now...<br></div><div>Eliot, does it ring some bell?<br></div></div><br></blockquote><div><br></div><div>Ah, forget it, I thought it was overwriting, but it is the first write on yet virgin methodeZone...</div><div>(it's just that the scenario was different from all the previous run)<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 22 sept. 2019 à 11:21, Jan Vrany <<a href="mailto:jan.vrany@fit.cvut.cz" target="_blank">jan.vrany@fit.cvut.cz</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> <br>
On 2019-09-22 10:57, Nicolas Cellier wrote:<br>
> Hi Jan,<br>
> Thanks, a recording debugger would indeed be a tremendous help!<br>
> Unfortunately, I'm unable to reproduce the bug under linux, only<br>
> macosx...<br>
> Do you know something equivalent to rr for mac?<br>
<br>
No, I don't. There might be something though, I never had a mac...<br>
<br>
Jan<br>
<br>
> <br>
> Le dim. 22 sept. 2019 à 09:55, Jan Vrany <<a href="mailto:jan.vrany@fit.cvut.cz" target="_blank">jan.vrany@fit.cvut.cz</a>> a<br>
> écrit :<br>
> <br>
>> Hi,<br>
>><br>
>>><br>
>>> - can anyone think of any other strategies I might take to try and<br>
>>> reproduce this?<br>
>>><br>
>> at the risk of stating the obvious, in cases similar to this rr (+<br>
>> VDB)<br>
>> helped<br>
>> me many times. See <a href="https://www.youtube.com/watch?v=Qbu4ED8wPYE" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=Qbu4ED8wPYE</a><br>
>><br>
>> Never used with opensmalltalk VM, though.<br>
>><br>
>> HTH, Jan<br>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div>