That's the bug. Fix coming!
Simon
On 02/09/13 05:46, Austin Seipp wrote:
I (think) I see the problem, but maybe I'm just tired and shooting in the dark.
The only time checkUnload really iteratively calls free is in
CheckUnload.c (I say 'iteratively', because the fact you're
touching/freeing b
> Ryan, can you do one final thing? When you run that program, be sure
> to specify `+RTS -Dl` (must be linked with -debug.) This will enable
> all the debug output where the linker is concerned. There will be a
> few hundred lines just for initialization (based on my machine.) If my
> theory is co
I (think) I see the problem, but maybe I'm just tired and shooting in the dark.
The only time checkUnload really iteratively calls free is in
CheckUnload.c (I say 'iteratively', because the fact you're
touching/freeing blocks inside already free blocks make me
suspicious.) The relevant code is:
-
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 (u
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
Excerpts from Ryan Newton's message of Sun Sep 01 19:54:34 -0700 2013:
> 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:
Well, that's because that's not what make is running:
./linker_unload $(BASE) $(GHC_PR
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
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
$
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
>
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
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: GarbageCollec
11 matches
Mail list logo
