<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Am 31.10.2013 um 01:15 schrieb Gary Byers <<a href="mailto:gb@clozure.com">gb@clozure.com</a>>:</div><br><blockquote type="cite">On Wed, 30 Oct 2013, Paul Meurer wrote:<br><blockquote type="cite">I run it now with --no-init and in the shell, with no difference. Immediate failure with :consing in *features*,<br>bogus objects etc. after several rounds without :consing.<br></blockquote><br>So, I can't rant and rave about the sorry state of 3rd-party CL libraries, and<br>anyone reading this won't be subjected to me doing so ?<br><br>Oh well.<br><br>I was able to reproduce the problem by running your test 100 times, </blockquote><div><br></div><div>I am not able to provoke it at all on the MacBook, and I tried a lot.</div><br><blockquote type="cite">so apparently<br>I won't be able to blame this on some aspect of your machine. (Also unfortunate,<br>since my ability to diagnose problems that only occur on 16-core machines depends<br>on my ability to borrow such machines for a few months.)<br></blockquote><div><br></div><div>I think you can do without a 16-core machine. I am able to reproduce the failure quite reliably on an older 4-core machine with Xeon CPUs and SuSE, with slightly different code (perhaps to get the timing right):</div><div><br></div><div><div>(dotimes (j 100)</div><div> (print (ccl::all-processes))</div><div> (dotimes (i 8)</div><div> (process-run-function</div><div> (format nil "getstring-~a-~a" j i)</div><div> (lambda (i)</div><div> (let ((list ()))</div><div> (dotimes (i 500000)</div><div> (push (getstring) list)))</div><div> (print i))</div><div> i))</div><div> (print (list :done j))</div><div> (sleep 1))</div><div><br></div></div><div>If you really need a 16-core machine to debug this I can give you access to mine. :-)</div><br><blockquote type="cite"><blockquote type="cite">My machine has 16 true cores and hyperthreading; I am running CentOS 6.0, and a recent CCL 1.9 (I did svn update +<br>rebuild of everything yesterday).<br>I also observed that the problem goes away when I replace the constant string in the library by a freshly<br>allocated string:<br>char *getstring() {?<br>? int index;<br>? char *buffer = (char *)calloc(100 + 1, sizeof(char));<br>? for (index = 0; index < 100; index++) {<br>? ? ? buffer[index] = 'a';<br>? ? }<br>? buffer[100] = '\0';<br>? return buffer ;<br>}<br>One should expect the strings in the Postgres library to be freshly allocated, but nevertheless they behave like<br>the constant string example.<br></blockquote><br>It's unlikely that this change directly avoids the bug (whatever it is); it's more<br>likely that it affects timing (exactly what happens when.) I don't yet know what<br>the bug is, but I think that it's likely that it's fair to characterize the bug<br>as being "timing-sensitive". (For example: from the GC's point of view, whether<br>a thread is running Lisp or foreign code when that thread is suspended by the GC.<br>The transition between Lisp and foreign code takes a few instructions, and if<br>a thread is suspended in the middle of that instruction sequence and the GC<br>misintrprets its state, very bad things like what you're seeing could occur.<br>That's not supposed to be possible, but something broadly similar seems to be<br>happening.)<br></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; font-family: 'Lucida Grande'; border-spacing: 0px; ">-- <br>Paul</span>
</div>
<br></body></html>