GHC 6.4.3 is stalled
Gregory Wright
gwright at comcast.net
Fri Jul 28 05:32:50 EDT 2006
On Jul 28, 2006, at 3:58 AM, Simon Marlow wrote:
> Hi Greg,
>
> Gregory Wright wrote:
>
>> Some data and a few questions:
>> 1. The failure on FreeBSD is not the same as on OS X. I built 6.4.2
>> from cvs on FreeBSD 6.1, and ran the ghc-regress tests. The tests
>> took a long time to run (about 14 hours on a dual Xeon 2.8 GHz
>> with 2 GB of memory). Towards the end of the tests, there were
>> about 30 "timeout" processes running, apparently doing nothing
>> but consuming cpu cycles.
>
> Ok, this is certainly a problem with forkOS in the threaded RTS in
> 6.4.2 on FreeBSD. I probably need to get access to a FreeBSD box
> to fix this myself, the code is pretty delicate (and sadly it has
> completely changed in 6.6, too).
>
> It might be worth trying with -lthr instead of -lpthread, according
> to Robert Watson. This switches to an alternative, 1:1, threading
> library.
>
I can try this. If you need access to a FreeBSD 6.1 box (dual 2.8
GHz Xeon, 2 G RAM),
I can set up ssh access for you. Let me know.
>
>> 2. Notes on reproducing the FreeBSD 6.4.2 build: I used
>> fpconfig from the ghc-6-4 branch;
>> ghc, libraries, hslibs and testsuite from the ghc-6-4-2 branch;
>> gnu make 3.80;
>> autoconf 2.59.
>> Gnu make 3.81 went into an infinite loop, much as gnu make 3.79
>> did when building ghc on OS X.
>
> That's odd, the fix for make 3.79 is in the 6.4.2 tree (rev.
> 1.82.2.2 of mk/suffix.mk). Something else must be happening with
> 3.81, sigh.
>
Yes, seems to be one of those things. I'm not going to look at it,
since using
3.80 seems to work well enough at the moment.
>> 3. Did the threaded RTS work on 6.4.1? Was it used by default?
>
> Presumably not. In 6.4.2 we switched to using the threaded RTS by
> default for GHC itself, which has forced the problem to the
> surface. Also there were some changes to the timeout program in
> the testsuite, which have apparently forced some other problems to
> the surface.
>
>> I can provide an RTS thread listing (+RTS -Ds) if that would be a
>> starting
>> point. Someone would have to explain what it means to me, though.
>> 4. When running with debugging turned on, I have seen the
>> assertion failure
>> ghc-6.4.2: internal error: ASSERTION FAILED: file GC.c, line 4356
>> Please report this as a compiler bug. See:
>> http://www.haskell.org/ghc/reportabug
>> This points toward the stack being corrupted. Maybe a thread
>> overflowing
>> its stack? I'm not sure. The assertion that fails is
>> ASSERT(frame < bottom);
>> It looks as if something has messed up the stack before this.
>
> Ok, it would help to find a smaller program that crashes with -
> threaded: debugging GHC itself is quite hard because it's difficult
> to get a deterministic run and hence reproducibility. Look at
> your testsuite failures and find threaded failures that aren't due
> to the compiler crashing (or just build stage2 without -threaded
> and run the testsuite again). Tests in concurrent/ are a good bet.
>
> When we have a smallish program that crashes, we can start debugging.
>
I will do a build and look at the failing tests to isolate a simple
case.
Here's another data point: Joel Reymont said that his OS X/intel
builds do not
crash during the testsuite (nothing in the CrashReporter logs). But
he mentioned
that he saw the accumulation of "timeout" processes. Earlier this
week, I
acquired a MacBook and have just finished loading ghc onto it. I
will try
to reproduce his result.
That information, if true, is a bit discouraging. It seems to say
that the problem
on intel may be different from that on ppc. In particular, the
compiler crashes
may only be happening on ppc. Yuck. I will verify whether this is so.
Best Wishes,
Greg
>> I am willing to dig into this, but I need a bit more help with
>> where to start.
>
> Thanks for your help!
>
> Cheers,
> Simon
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
More information about the Glasgow-haskell-users
mailing list