<div dir="ltr"><div>No idea if this is related or not,</div><div>but i got regular crash on macos own compiled x64 artefact by just running:</div><div> SocketTest suite run.</div><div><br></div><div>I first though about inquiring some UB, but this happens in debug version, so it's probably something else.</div><div>I did not try to simulate (but can we simulate socket tests?).<br></div><div>This does not happen in windows 64 nor linux 64 (wsl) where I can run all the tests.</div><div>Note that on wsl i had to evaluate (Compiler recompileAll) in trunk6-64.image, otherwise a bunch of tests are failing... Mysterious.</div><div>I also had 2 ByteSymbol differing from their interned version.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 14 sept. 2019 à 09:33, Tobias Pape <<a href="mailto:Das.Linux@gmx.de">Das.Linux@gmx.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> On 14.09.2019, at 06:03, Nicola Mingotti <<a href="mailto:nmingotti@gmail.com" target="_blank">nmingotti@gmail.com</a>> wrote:<br>
> <br>
> <br>
> I can help you a bit only on this point:<br>
> "- is there a way of introducing network delays in Mac OS that might help me induce the bug?"<br>
<br>
Yea it is called "network link conditioner.prefpane" :D<br>
<br>
<br>
> <br>
> Yes, in theory it is possible. Some time ago I red the documentation of 'dummynet' in FreeBSD for the firewall 'ipfw', it seemed to be very interesting but I never had occasion to use it.<br>
> <br>
> Now, Apple Unix is in large part taken from FreeBSD => I check if they took also dummynet:<br>
> macOS> apropos dummynet<br>
> dummynet(4) .... <br>
> <br>
> So, yes, it is there.<br>
> <br>
> HTH<br>
> <br>
> bye<br>
> Nicola<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> On 9/13/19 8:15 PM, Eliot Miranda wrote:<br>
>> Hi All,<br>
>> <br>
>> there is a VM bug in 64-bit Spur with the Sista V1 bytecode set and full blocks. The symptom is that when waiting for a remote Monticello repository to update and/or deliver a package version the system crashes in JITTED code after what appears to be some kind of wait.<br>
>> <br>
>> This is a reliably occurring bug b ut maddeningly difficult to reproduce. The bug reliably occurs when interacting with a remote rep[ository (e.g. <a href="http://source.squeak.org/VMMaker" rel="noreferrer" target="_blank">http://source.squeak.org/VMMaker</a>) when the server is "cold", and hence makes the image wait. Every time I have tried to repeat the failing sequence the crash has not occurre3d, I think because the server is now "hot" and serves up the version quickly. Today I even tried shutting down my machine for over an hour and rebooting. But I could not get the crash to occur even though it seems to me that every time I try it the first time in the4 day it does crash.<br>
>> <br>
>> This is an important bug to fix. If it cannot be fixed then full blocks and Sista V1 are not ready for use in the upcoming Squeak release. I am looking for help in debugging this.<br>
>> <br>
>> - is anyone else uising the 64-bit VM with full blocks and Sista V1 who sees hard VM crashes? If so, under what circumstances?<br>
>> <br>
>> - is it possible to flush caches in the <a href="http://source.squeak.org/VMMaker" rel="noreferrer" target="_blank">http://source.squeak.org/VMMaker</a> server, or could people tolerate me rebooting the server?<br>
>> <br>
>> - is there a way of introducing network delays in Mac OS that might help me induce the bug?<br>
>> <br>
>> - can anyone think of any other strategies I might take to try and reproduce this?<br>
>> <br>
>> I may have to try and reproduce e the bug in the simulator to have a chance of identifying the bug. Does anyone have a good enough mental model of the Monticello server interaction and have energy to help me figure this one out?<br>
>> <br>
>> Here is some information from the last crash I did see in the debugger (alas it is incomplete; there are a number of additional pieces of info I could have collected).<br>
>> <br>
>> (lldb) thr b<br>
>> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)<br>
>> * frame #0: 0x000000010de5700a<br>
>> frame #1: 0x000000010dd7b174<br>
>> frame #2: 0x000000010dd45f1c<br>
>> frame #3: 0x000000010dd44534<br>
>> frame #4: 0x000000010dd44c60<br>
>> (lldb) x/10i 0x000000010de5700a<br>
>> <br>
>> (lldb) call printStackCallStackOf($rbp)<br>
>> 0x7ffeefbdfc30 M Heap>upHeap: 0x11273ca90: a(n) Heap<br>
>> 0x7ffeefbdfc68 M Heap>add: 0x11273ca90: a(n) Heap<br>
>> 0x7ffeefbdfca0 M Delay class>scheduleDelay:from: 0x1123ebfb8: a(n) Delay class<br>
>> 0x7ffeefbdfcf0 M Delay class>handleTimerEvent 0x1123ebfb8: a(n) Delay class<br>
>> 0x7ffeefbdfd20 M Delay class>runTimerEventLoop 0x1123ebfb8: a(n) Delay class<br>
>> <br>
>> (lldb) x/10i 0x000000010dd7b174<br>
>> 0x10dd7b174: 48 8b 55 10 movq 0x10(%rbp), %rdx<br>
>> 0x10dd7b178: 48 89 ec movq %rbp, %rsp<br>
>> 0x10dd7b17b: 5d popq %rbp<br>
>> 0x10dd7b17c: c2 10 00 retq $0x10<br>
>> 0x10dd7b17f: cc int3<br>
>> 0x10dd7b180: cc int3<br>
>> 0x10dd7b181: cc int3<br>
>> 0x10dd7b182: cc int3<br>
>> 0x10dd7b183: cc int3<br>
>> 0x10dd7b184: cc int3<br>
>> (lldb) print whereIs(0x000000010dd7b174)<br>
>> (char *) $0 = 0x00000001000f83ff " is in generated methods"<br>
>> (lldb) call printCogMethodFor((void *)0x000000010dd7b174)<br>
>> 0x10dd7afc0 <-> 0x10dd7b198: method: 0x112f23c10 selector: 0x112232c20 add:<br>
>> (lldb) print whereIs(0x000000010de5700a)<br>
>> (char *) $1 = 0x00000001000f83ff " is in generated methods"<br>
>> (lldb) call printCogMethodFor((void *)0x000000010de5700a)<br>
>> 0x10de56ba0 <-> 0x10de57078: method: 0x1126ec218 prim 23856 selector: 0x7ffeefbf3d20<br>
>> <br>
>> this method ends up being the fitted version of Delay class>> startTimerEventLoop<br>
>> _,,,^..^,,,_<br>
>> best, Eliot<br>
>> <br>
>> <br>
> <br>
> <br>
<br>
<br>
<br>
</blockquote></div>