<div dir="ltr">Hi Austin,<div><br></div><div>Should have said -- this is 64-bit RHEL 6 (my academic departments standardized configuration).</div><div><br></div><div> $ uname -a </div><div>     Linux  2.6.32-358.14.1.el6.x86_64 #1 SMP Mon Jun 17 15:54:20 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux<br>

</div><div><br></div><div>Weirdly it seems to have a different behavior when run by &quot;make&quot; and by hand.  When I run the make command you provided it segfaults with error code 2:</div><div><br></div><div><div><font face="courier new, monospace" size="1"><b>cd . &amp;&amp; $MAKE -s --no-print-directory linker_unload    &lt;/dev/null &gt;linker_unload.run.stdout 2&gt;linker_unload.run.stderr</b></font></div>

<div><font face="courier new, monospace" size="1"><b>Wrong exit code (expected 0 , actual 2 )</b></font></div><div><font face="courier new, monospace" size="1"><b>Stdout:</b></font></div><div><font face="courier new, monospace" size="1"><b>Stderr:</b></font></div>

<div><font face="courier new, monospace" size="1"><b>make[1]: *** [linker_unload] Segmentation fault (core dumped)</b></font></div><div><font face="courier new, monospace" size="1"><b>*** unexpected failure for linker_unload(normal)</b></font></div>

<div><font face="courier new, monospace" size="1"><b>Unexpected results from:</b></font></div><div><font face="courier new, monospace" size="1"><b>TEST=&quot;linker_unload&quot;</b></font></div></div><div><br></div><div>
But then when I run it by hand with &quot;./linker_unload&quot; or &quot;valgrind ./linker_unload&quot; I get an unknown symbol error with exit code 1:</div>
<div><br></div><div><div><b><font face="courier new, monospace" size="1">==70613==</font></b></div><div><b><font face="courier new, monospace" size="1">linker_unload: Test.o: unknown symbol `base_GHCziNum_zdfNumInt_closure&#39;</font></b></div>

<div><b><font face="courier new, monospace" size="1">linker_unload: resolveObjs failed</font></b></div><div><b><font face="courier new, monospace" size="1">==70613==</font></b></div><div><b><font face="courier new, monospace" size="1">==70613== HEAP SUMMARY:</font></b></div>

</div><div><br></div><div><br></div><div>   -Ryan</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Sep 1, 2013 at 10:46 PM, Austin Seipp <span dir="ltr">&lt;<a href="mailto:aseipp@pobox.com" target="_blank">aseipp@pobox.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have also not seen this test fail on amd64/Linux since Simon<br>
committed it. From the valgrind output, it looks like your machine is<br>
32bit, correct Ryan? Edward told me yesterday on IRC he saw this fail<br>
on 64bit Linux, so I&#39;m a little confused.<br>
<br>
Can you please try this?<br>
<br>
$ cd testsuite/tests/rts<br>
$ make TEST=&quot;linker_unload&quot; EXTRA_HC_OPTS=&quot;-debug&quot;<br>
$ valgrind ./linker_unload<br>
<br>
This will link you with a debug copy of the RTS, so Valgrind/GDB can<br>
relate errors back to the relevant source code. Perhaps this will help<br>
shed light on your problem.<br>
<div><div class="h5"><br>
<br>
On Sun, Sep 1, 2013 at 9:39 PM, Edward Z. Yang &lt;<a href="mailto:ezyang@mit.edu">ezyang@mit.edu</a>&gt; wrote:<br>
&gt; However, as far as I can tell, it is not 100% reproduceable.<br>
&gt; In a recent validate of 5f98d44d8617756971cf47c040f2556de4e98f63,<br>
&gt; this test does not fail.<br>
&gt;<br>
&gt; Edward<br>
&gt;<br>
&gt; Excerpts from Edward Z. Yang&#39;s message of Fri Aug 30 21:55:29 -0700 2013:<br>
&gt;&gt; Yes, this one is failing for me too. Probably related to the<br>
&gt;&gt; recent object unload patch for <a href="http://ghc.haskell.org/trac/ghc/ticket/8039" target="_blank">http://ghc.haskell.org/trac/ghc/ticket/8039</a><br>
&gt;&gt;<br>
&gt;&gt; Excerpts from Ryan Newton&#39;s message of Fri Aug 30 21:51:<a href="tel:24%20-0700%202013" value="+12407002013">24 -0700 2013</a>:<br>
&gt;&gt; &gt; That test builds an executable named &#39;linker_unload&#39; which segfaults for<br>
&gt;&gt; &gt; me.  Valgrind says this:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;     ==42800== Invalid read of size 8<br>
&gt;&gt; &gt;     ==42800==    at 0x66945F: checkUnload (in<br>
&gt;&gt; &gt; /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload)<br>
&gt;&gt; &gt;     ==42800==    by 0x657F7A: GarbageCollect (in<br>
&gt;&gt; &gt; /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload)<br>
&gt;&gt; &gt;     ==42800==    by 0x651790: scheduleDoGC (in<br>
&gt;&gt; &gt; /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload)<br>
&gt;&gt; &gt;     ==42800==    by 0x6518B4: performGC_ (in<br>
&gt;&gt; &gt; /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload)<br>
&gt;&gt; &gt;     ==42800==    by 0x403BB1: main (in<br>
&gt;&gt; &gt; /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload)<br>
&gt;&gt; &gt;     ==42800==  Address 0x5bfdd20 is 80 bytes inside a block of size 120<br>
&gt;&gt; &gt; free&#39;d<br>
&gt;&gt; &gt;     ==42800==    at 0x4C273F0: free (vg_replace_malloc.c:446)<br>
&gt;&gt; &gt;     ==42800==    by 0x66945E: checkUnload (in<br>
&gt;&gt; &gt; /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload)<br>
&gt;&gt; &gt;     ==42800==    by 0x657F7A: GarbageCollect (in<br>
&gt;&gt; &gt; /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload)<br>
&gt;&gt; &gt;     ==42800==    by 0x651790: scheduleDoGC (in<br>
&gt;&gt; &gt; /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload)<br>
&gt;&gt; &gt;     ==42800==    by 0x6518B4: performGC_ (in<br>
&gt;&gt; &gt; /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload)<br>
&gt;&gt; &gt;     ==42800==    by 0x403BB1: main (in<br>
&gt;&gt; &gt; /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload)<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; This went the same across a couple different independent checkouts.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;   -Ryan<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; ghc-devs mailing list<br>
&gt; <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
&gt; <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
Regards,<br>
Austin - PGP: 4096R/0x91384671<br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
</font></span></blockquote></div><br></div>