Hi All,<div><br></div><div>    responding to Andrew here because this is generally of interest to the vm-list.<br><br><div class="gmail_quote">On Mon, Sep 26, 2011 at 11:06 AM, Andrew Gaylard <span dir="ltr">&lt;<a href="mailto:apg@4dst.com">apg@4dst.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hmmm.  Thanks for the advice -- we now build with -O3, and all&#39;s well.<br>
I&#39;ve run the VM at full load (mostly compiling) for 30 hours without a<br>
hiccup.  Interesting that -O2 is problematic, but -O3 isn&#39;t; I assumed<br>
that higher optimisations would make things less stable, not more so.<br>
And we get a 17% speed increase.<br>
<br>
        My GCC is:<br>
        $ gcc --version<br>
        gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3<br></blockquote><div><br></div><div>So this really surprises me since we see exactly the same thing with gcc version 3.4.6 20060404 (Red Hat 3.4.6-3).  If we compile with -O1 or -O3 we get functional Cog VMs, but -O2 crashes on start-up or soon there-after.  I&#39;m surprised that two very different versions of gcc show the same behaviour but I guess I shouldn&#39;t be.  Some time some of us (me included) could really do to put the effort into understanding what the issue is.  It could be a gcc bug or it could be that we&#39;re generating C code with ill-defined behaviour.  I have to say that I suspect the latter given how different gcc 3.4.x and gcc 4.4.x are (BTW Andrew also sees the same issue with gcc 4.1.x).</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
- Andrew<br>
</font><div class="im"><br>
On 2011.09.25 23:12:50 -0700, Eliot Miranda &lt;<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>&gt; wrote:<br>
&gt; On Sat, Sep 24, 2011 at 9:02 AM, Andrew Gaylard &lt;<a href="mailto:apg@4dst.com">apg@4dst.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Actually, it looks like I was wrong.  After rebuiding everything from<br>
&gt; &gt; scratch, I&#39;ve been unable to reproduce these crashes, except for the<br>
&gt; &gt; one with unix-4.4.7.image.<br>
&gt; &gt;<br>
&gt; &gt; Sorry for the false alarm.  r2495 looks pretty good, at both -O0 and<br>
&gt; &gt; -O1.  It still crashes at -O2, but that&#39;s not a huge concern.<br>
&gt; &gt;<br>
&gt;<br>
&gt; Which gcc are you using?  Here at Cadence on a much older 32-bit machine<br>
&gt; using gcc 3.4.x we see crashes at -O2 but no crashes at -O0 -O1 &amp; -O3 :)<br>
&gt;<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
</div><div><div></div><div class="h5">&gt; &gt; On 2011.09.24 08:07:47 +0200, Andrew Gaylard &lt;<a href="mailto:apg@4dst.com">apg@4dst.com</a>&gt; wrote:<br>
&gt; &gt; &gt; On 2011.09.23 13:26:06 -0700, Eliot Miranda &lt;<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>&gt;<br>
&gt; &gt; wrote:<br>
&gt; &gt; &gt; &gt; Thank you, Andrew, you nailed it.  I&#39;ve found the bug via your stack<br>
&gt; &gt; trace<br>
&gt; &gt; &gt; &gt; below.  Huge relief.  Thanks!  New VMs and explanation to the list<br>
&gt; &gt; soon.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Alas, we spoke too soon.  -2495 exhibits the same symptoms; traces and<br>
&gt; &gt; &gt; gdb transcripts are attached.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; - vm-*-2495.0.txt are from our basic.image, running the test-runner.<br>
&gt; &gt; &gt; - vm-*-2495.1.txt are from Squeak4.2-10966.image, running the<br>
&gt; &gt; test-runner.<br>
&gt; &gt; &gt; - vm-*-2495.2.txt are from unix-4.4.7.image, having just started up the<br>
&gt; &gt; VM.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The first two of these appear to be the same problem I encountered<br>
&gt; &gt; &gt; with -2493.  The backtraces certainly look very similar.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The third one is rather different. Looking at the stack trace, the<br>
&gt; &gt; &gt; &#39;rcvr&#39; variable in ceSendsupertonumArgs is 17039140, which is<br>
&gt; &gt; &gt; de-referenced in line 10733, causing a SEGV; the handler duly confirms<br>
&gt; &gt; &gt; the faulting address as si_addr = 0x103ff24:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;       $ perl -e &#39;print 0x103ff24&#39;<br>
&gt; &gt; &gt;       17039140<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>
</div>