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
>
Hello Luke,
Thanks for the note. I'm testing on OS X 10.8.4, Xcode 4.6.3, and llvm-gcc
4.2.1
(I placed the scripts directory ghc-ios-scripts-master at the front of
PATH).
LVM Build is 2336.11.00.
I fetched GHC sources and tried to build using:
$ git clone git://git.haskell.org/ghc.git
$ cd ghc
$
Hi Dominick,
Hm, this should have been fixed by
http://ghc.haskell.org/trac/ghc/ticket/7700 .
When you say you downloaded GHC, do you mean you cloned GHC HEAD (e.g. git
clone git://git.haskell.org/ghc.git ?) — the patches have only just landed
: ).
Also can you give us an idea of what your build
Hi,
I followed the instructions on the link, downloaded ghc, created build.mk,
etc.,
and configured for ghc-ios-sim. But the make fails with the message below.
Tried installing terminfo (cabal install terminfo) but this didn't help...
ghc $ make
===--- building phase 0
make -r --no-print-director
Hello Jan,
As far as I can tell, this should be handled using the standard
procedure for externally maintained bootstrap libraries:
http://ghc.haskell.org/trac/ghc/wiki/Repositories/Upstream
You should coordinate with Roman about this. In the worst case,
you can manually make a new (GHC-spe
Have not looked at patch.
Excerpts from David Luposchainsky's message of Sun Sep 01 12:23:06 -0700 2013:
> 1. Validation does not work due to the warnings issued. Since "sh
> validate" uses -Werror, an AMP warning will stop the compilation before
> tests can even be run. Unfortunately, the build s
If you mean the nightly validation runs, then yes - Geoffrey turned them off
before leaving MSR.
Janek
Dnia piątek, 30 sierpnia 2013, Edward Z. Yang napisał:
> The last nightly I see is from the 22nd; did they get turned off?
>
> Edward
>
> ___
> ghc-d
Hey ghc-devs,
I finished #8004. The patch introduces a new compiler flag,
"-fwarn-amp", that is on by default. The changes are pretty local,
affecting TcRnDriver.lhs, PrelNames.lhs and DynFlags.hs, and you can
view it here:
https://github.com/quchen/ghc/compare/amp_warnings?expand=1
(Note that t
On Sun, Sep 1, 2013 at 8:55 PM, Ryan Newton wrote:
> Earlier this summer I had no problem with "configure; make; make
> install" But recently I'm getting errors like this on GHC HEAD:
>
> /u/rrnewton/opt/ghc-7.7.20130831/lib/ghc-7.7.20130831/bin/ghc-pkg: error
> while loading shared libraries:
Earlier this summer I had no problem with "configure; make; make install"
But recently I'm getting errors like this on GHC HEAD:
/u/rrnewton/opt/ghc-7.7.20130831/lib/ghc-7.7.20130831/bin/ghc-pkg:
error while loading shared libraries: libHSbin-package-db-0.0.0
.0-ghc7.7.20130831.so: cannot ope
Thanks!
This seems to do the trick wonderfully.
-ghclibdir = $(libdir)/ghc-$(ProjectVersion)
+ghclibdir = $(libdir)/$(CrossCompilePrefix)ghc-$(ProjectVersion)
I've just done a clean build with this and it's working perfectly.
On Sat, Aug 31, 2013 at 2:26 PM, Gabor Greif wrote:
> On 8/
17 matches
Mail list logo
