mm it seems to be OK !<div><br></div><div>I will try deeper tests later and let you know if I have this problem again</div><div><br></div><div>Thank you for your work ;-)<br><br><div class="gmail_quote">On Thu, Feb 14, 2013 at 8:58 AM, Gary Byers <span dir="ltr"><<a href="mailto:gb@clozure.com" target="_blank">gb@clozure.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I made a change to the trunk kernel source that seemed to fix the problem for<br>
me while running 9.1/amd64 under a VMware VM. (VMware made the VM appear to<br>
have AVX.) I wanted to try to test it on some real AVX-enabled hardware;<br>
unfortunately, the only AVX-enabled hardware I have has network adapters<br>
that were made less than 5 years ago and are therefore a total mystery to<br>
FreeBSD ...<br>
<br>
I'll keep wrestling with that (may be able to find a supported USB->ethernet<br>
or USB->wifi adapter); if people who use FreeBSD 9.1 on amd64 could test<br>
these changes, that'd be helpful.<br>
<br>
The changes are just in source in the trunk and they only affect the lisp<br>
kernel, so to test them you need to:<br>
<br>
1) check out or "svn update" a copy of the "freebsdx86" tree from the trunk.<br>
2) do:<div class="im"><br>
<br>
$ cd ccl/lisp-kernel/freebsdx8664<br>
$ make<br></div>
$ cd ../..<br>
$ ./fx86cl64<br>
<br>
I find that I can do things like:<br>
<br>
? (dotimes (i 10) (rebuild-ccl :full t))<br>
<br>
reliably after those changes; before they were made, that would die on<br>
the first or second iteration with a cryptic message from the<br>
'sigreturn' system call (often the same message that people have<br>
reported, occasionally something different but just as cryptic.)<br>
<br>
The old saying ("testing can confirm the presence of bugs but doesn't<br>
prove their absence") seems to apply here: I haven't been able to<br>
provoke the bug yet, but I'm not 100% confident that I understand why<br>
the change avoids the problem. (The change has to do with how<br>
"alternate signal stacks" are allocated and the symptom has been that<br>
a stack-allocated data structure that describes the state of a thread<br>
when an exception occurs is apparently getting corrupted in some way<br>
so that it can't be used to restore the thread's state ("sigreturn")<br>
sometimes. Those things are at least somewhat related, but I don't<br>
fully understand how one thing (the old way of allocating stacks for<br>
signal processing) causes the other (corruption of the signal context.)<div class="im HOEnZb"><br>
<br>
<br>
On Sun, 10 Feb 2013, Mark Cox wrote:<br>
<br>
</div><div class="HOEnZb"><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 10/02/2013, at 10:06 AM, R. Matthew Emerson wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Feb 9, 2013, at 6:55 PM, Mark Cox <<a href="mailto:markcox80@gmail.com" target="_blank">markcox80@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 09/02/2013, at 1:14 AM, Gary Byers wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I was able to run 9.1 under VMware and think/hope that this is now fixed<br>
in the CCL trunk. If people who can reproduce this could try the trunk,<br>
that'd be helpful.<br>
</blockquote>
<br>
I fresh checkout of trunk does the following on both of my virtual machines:<br>
<br>
$ ./fx86cl64<br>
Unhandled exception 10 at 0x300001050b6b, context->regs at #x7fffffffd280<br>
received signal 10; faulting address: 0x300001050b6b<br>
? for help<br>
[88099] Clozure CL kernel debugger:<br>
<br>
I installed misc/compat6x as stated in [1].<br>
</blockquote>
<br>
Can you please try it with a locally-built lisp kernel? That is, do<br>
<br>
cd lisp-kernel/freebsdx8664 && make clean && make<br>
</blockquote>
<br>
My apologies. I did not do this.<br>
<br>
The Core 2 Duo rebuilds fine, but the Core i7 signals the same error as originally reported by Cyrille.<br>
<br>
Mark<br>
______________________________<u></u>_________________<br>
Openmcl-devel mailing list<br>
<a href="mailto:Openmcl-devel@clozure.com" target="_blank">Openmcl-devel@clozure.com</a><br>
<a href="http://clozure.com/mailman/listinfo/openmcl-devel" target="_blank">http://clozure.com/mailman/<u></u>listinfo/openmcl-devel</a><br>
<br>
<br>
</blockquote>
______________________________<u></u>_________________<br>
Openmcl-devel mailing list<br>
<a href="mailto:Openmcl-devel@clozure.com" target="_blank">Openmcl-devel@clozure.com</a><br>
<a href="http://clozure.com/mailman/listinfo/openmcl-devel" target="_blank">http://clozure.com/mailman/<u></u>listinfo/openmcl-devel</a><br>
</div></div></blockquote></div><br></div>