<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Thanks for looking at this, Matthew.</div><div class=""><br class=""></div><div class="">Here is an update that pins down the problem further:</div><div class=""><br class=""></div><div class=""><a href="https://pastebin.com/zvfyL4Dj" class="">https://pastebin.com/zvfyL4Dj</a></div><div class=""><br class=""></div><div class="">the with-lock macro here is a clone of ccl:with-lock-grabbed, except it checks ownership of the lock before and after the body.</div><div class=""><br class=""></div><div class="">It apparently shows that a lock held by a thread is often stolen by another thread, even in the absence of GC.</div><div class=""><br class=""></div><div class="">Specifically, running (threadtest2 :exercise-locking t) causes “ERR2”, where a test after the body of the macro indicates that a lock has been stolen by another thread.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Going deeper may require a knowledge of Arm cpu instructions.</div><div class=""><br class=""></div><div class="">The culprit seems to be in l0-misc.lisp, function #-futex %lock-recursive-lock-ptr</div><div class=""><br class=""></div><div class="">Wild ill-informed speculation: This Arm manual</div><div class=""><a href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0008a/ch01s03s02.html" class="">http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0008a/ch01s03s02.html</a></div><div class="">suggests that a DMB instruction is needed after a lock operation, but disassembling</div><div class="">ccl::%lock-recursive-lock-ptr doesn’t show this instruction, assuming everything it does is inlined.</div><div class=""><br class=""></div><div class="">John</div><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 11, 2019, at 7:13 PM, R. Matthew Emerson <<a href="mailto:rme@acm.org" class="">rme@acm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class="Apple-interchange-newline"><br class=""><blockquote type="cite" class=""><div class="">On Jan 11, 2019, at 3:34 PM, JTK <<a href="mailto:jetmonk@gmail.com" class="">jetmonk@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br class=""><div class=""><br class=""></div><div class="">Apologies for these piece-wise emails.</div><div class=""><br class=""></div><div class="">I tried to replicate armcl threading problems described in</div><div class=""><a href="https://trac.clozure.com/ccl/ticket/1257" class="">https://trac.clozure.com/ccl/ticket/1257</a> </div><div class="">and I think I might have found some other issues, as well as a clue to a possible cause</div><div class=""><br class=""></div><div class="">See <a href="https://pastebin.com/2x3mcHMc" class="">https://pastebin.com/2x3mcHMc</a></div><div class=""><br class=""></div><div class="">I found that </div><div class=""><br class=""></div><div class="">* a simple thread test with a bit of garbage generation in threads fails with Unhandled Exception 4 on armcl 1.12-dev (v1.12-dev.4-3-gdd5622e9), but does not fail in release version v1.11.5 </div><div class=""><br class=""></div><div class="">* If I put a lock around the garbage generation (just a make-string), to exercise locking in threads, in v1.11.5 it fails with <span class="Apple-tab-span" style="white-space: pre;"> </span>“Current process #<PROCESS Reader 4(26) [Active] #x150D335E> does not own lock #<RECURSIVE-LOCK "glock" [ptr @ #x76105C60] #x150BB0D6> in CCL::%UNLOCK-RECURSIVE-LOCK-OBJECT"</div><div class=""><br class=""></div><div class="">Is it possible that imperfect locking (race condition? non atomicity?) in the armcl implementation causes bug 1257, mimicking a GC bug? </div></div></div></blockquote><br class=""></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">The last time I tried hard to find this bug I utterly failed to find it.</div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">I pasted your comments into the Trac ticket (and I'll be to copying the whole issue over to GitHub soon).</div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">-m</div></div></blockquote></div><br class=""></body></html>