Ah, yes I see. Well, giving it the proper arguments when running via valgrind puts me back to an "Invalid read" segfault. I confirmed that the linker_unload executable itself is 64 bit:
$ file linker_unload linker_unload: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped ==72103== Command: ./linker_unload /home/beehive/ryan_scratch/ghc-working/libraries/base/dist-install/build/libHSbase-4.7.0.0.a /home/beehive/ryan_scratch/ghc-working/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0.a /home/beehive/ryan_scratch/ghc-working/libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0.a ==72103== ==72103== Invalid read of size 8 ==72103== at 0x479F9F: checkUnload (in /home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload) ==72103== by 0x4689DA: GarbageCollect (in /home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload) ==72103== by 0x4621F0: scheduleDoGC (in /home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload) ==72103== by 0x462314: performGC_ (in /home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload) ==72103== by 0x403341: main (in /home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload) ==72103== Address 0xf45ed70 is 80 bytes inside a block of size 120 free'd ==72103== at 0x4A063F0: free (vg_replace_malloc.c:446) ==72103== by 0x479F9E: checkUnload (in /home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload) ==72103== by 0x4689DA: GarbageCollect (in /home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload) ==72103== by 0x4621F0: scheduleDoGC (in /home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload) ==72103== by 0x462314: performGC_ (in /home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload) ==72103== by 0x403341: main (in /home/beehive/ryan_scratch/ghc-working/testsuite/tests/rts/linker_unload) ==72103== On Sun, Sep 1, 2013 at 11:01 PM, Austin Seipp <ase...@pobox.com> wrote: > Oops, should have said this: if you checkout the Makefile for > testsuite/tests/rts - at the very bottom - you'll see the > linker_unload target. When run, the executable needs some arguments so > it knows what to try and load: > > --- > ./linker_unload $(BASE) $(GHC_PRIM) $(INTEGER_GMP) > --- > > So you also need to provide the right arguments. Sorry about that! > > On Sun, Sep 1, 2013 at 9:54 PM, Ryan Newton <rrnew...@gmail.com> wrote: > > Hi Austin, > > > > Should have said -- this is 64-bit RHEL 6 (my academic departments > > standardized configuration). > > > > $ uname -a > > 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 > > > > Weirdly it seems to have a different behavior when run by "make" and by > > hand. When I run the make command you provided it segfaults with error > code > > 2: > > > > cd . && $MAKE -s --no-print-directory linker_unload </dev/null > >>linker_unload.run.stdout 2>linker_unload.run.stderr > > Wrong exit code (expected 0 , actual 2 ) > > Stdout: > > Stderr: > > make[1]: *** [linker_unload] Segmentation fault (core dumped) > > *** unexpected failure for linker_unload(normal) > > Unexpected results from: > > TEST="linker_unload" > > > > But then when I run it by hand with "./linker_unload" or "valgrind > > ./linker_unload" I get an unknown symbol error with exit code 1: > > > > ==70613== > > linker_unload: Test.o: unknown symbol `base_GHCziNum_zdfNumInt_closure' > > linker_unload: resolveObjs failed > > ==70613== > > ==70613== HEAP SUMMARY: > > > > > > -Ryan > > > > > > On Sun, Sep 1, 2013 at 10:46 PM, Austin Seipp <ase...@pobox.com> wrote: > >> > >> I have also not seen this test fail on amd64/Linux since Simon > >> committed it. From the valgrind output, it looks like your machine is > >> 32bit, correct Ryan? Edward told me yesterday on IRC he saw this fail > >> on 64bit Linux, so I'm a little confused. > >> > >> Can you please try this? > >> > >> $ cd testsuite/tests/rts > >> $ make TEST="linker_unload" EXTRA_HC_OPTS="-debug" > >> $ valgrind ./linker_unload > >> > >> This will link you with a debug copy of the RTS, so Valgrind/GDB can > >> relate errors back to the relevant source code. Perhaps this will help > >> shed light on your problem. > >> > >> > >> On Sun, Sep 1, 2013 at 9:39 PM, Edward Z. Yang <ezy...@mit.edu> wrote: > >> > However, as far as I can tell, it is not 100% reproduceable. > >> > In a recent validate of 5f98d44d8617756971cf47c040f2556de4e98f63, > >> > this test does not fail. > >> > > >> > Edward > >> > > >> > Excerpts from Edward Z. Yang's message of Fri Aug 30 21:55:29 -0700 > >> > 2013: > >> >> Yes, this one is failing for me too. Probably related to the > >> >> recent object unload patch for > >> >> http://ghc.haskell.org/trac/ghc/ticket/8039 > >> >> > >> >> Excerpts from Ryan Newton's message of Fri Aug 30 21:51:24 -0700 > 2013: > >> >> > That test builds an executable named 'linker_unload' which > segfaults > >> >> > for > >> >> > me. Valgrind says this: > >> >> > > >> >> > > >> >> > ==42800== Invalid read of size 8 > >> >> > ==42800== at 0x66945F: checkUnload (in > >> >> > > >> >> > > /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) > >> >> > ==42800== by 0x657F7A: GarbageCollect (in > >> >> > > >> >> > > /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) > >> >> > ==42800== by 0x651790: scheduleDoGC (in > >> >> > > >> >> > > /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) > >> >> > ==42800== by 0x6518B4: performGC_ (in > >> >> > > >> >> > > /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) > >> >> > ==42800== by 0x403BB1: main (in > >> >> > > >> >> > > /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) > >> >> > ==42800== Address 0x5bfdd20 is 80 bytes inside a block of size > >> >> > 120 > >> >> > free'd > >> >> > ==42800== at 0x4C273F0: free (vg_replace_malloc.c:446) > >> >> > ==42800== by 0x66945E: checkUnload (in > >> >> > > >> >> > > /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) > >> >> > ==42800== by 0x657F7A: GarbageCollect (in > >> >> > > >> >> > > /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) > >> >> > ==42800== by 0x651790: scheduleDoGC (in > >> >> > > >> >> > > /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) > >> >> > ==42800== by 0x6518B4: performGC_ (in > >> >> > > >> >> > > /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) > >> >> > ==42800== by 0x403BB1: main (in > >> >> > > >> >> > > /home/beehive/ryan_scratch/validate14/testsuite/tests/rts/linker_unload) > >> >> > > >> >> > This went the same across a couple different independent checkouts. > >> >> > > >> >> > -Ryan > >> > > >> > _______________________________________________ > >> > ghc-devs mailing list > >> > ghc-devs@haskell.org > >> > http://www.haskell.org/mailman/listinfo/ghc-devs > >> > >> > >> > >> -- > >> Regards, > >> Austin - PGP: 4096R/0x91384671 > >> > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs@haskell.org > >> http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > > > > -- > Regards, > Austin - PGP: 4096R/0x91384671 >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
