RE: More on the OS X crashes

Is the assertion failure always the same?  That would certainly help a
lot.

If you could also run the debugging compiler with +RTS -Ds, that will
tell us something about what it was doing before the crash.

The next step would be to run the compiler under gdb, stop at the
assertion failure and poke around in the thread structure to see what is
wrong.  To run the compiler under gdb you need to run the GHC binary
itself - take a look at the /usr/bin/ghc script to see what -B flag to
pass.

Cheers,
        Simon

On 16 May 2006 14:04, Gregory Wright wrote:

> Hi Simon,
> 
> Is there any documentation I should look at or could you just
> specify a set of files where the problem might lie?  I may be
> able to set aside a bit of time to work on this (especially since
> I have a project for a client that I would like to write using
> ghc-6.4.{2|3}.
> 
> Best Wishes,
> Greg
> 
> 
> On May 16, 2006, at 8:52 AM, Simon Marlow wrote:
> 
>> Thanks Greg.  Wolfgang Thaller has promised to take a look at this,
>> but I think he's quite busy at the moment.
>> 
>> Cheers,
>>      Simon
>> 
>> Gregory Wright wrote:
>>> Hi,
>>> I've built a compiler with debugging turned on and have obtained
>>> what might be useful information about the crashes on OS X.
>>> When I try to do a build, in this case, of NewBinary, I get
>>> --->  Configuring hs-NewBinary
>>> DEBUG: Executing proc-pre-com.apple.configure-configure-0
>>> 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
>>> Error: Target com.apple.configure returned: shell command "ghc -
>>> lintl  -o Setup Setup.lhs -package Cabal" returned error 254
>>> Command output: ghc-6.4.2: internal error: ASSERTION FAILED: file
>>> GC.c, line 4356 (The ghc output lines are bracketed by some
>>> darwinports status info.) I've seen the same assertion failure in
>>> other cases, but it is 
>>> not entirely repeatable.  Smells like something is not initialized
>>> or aligned correctly.  (I even got this error from compiling
>>> main = putStrLn "Hello, World!"
>>> but that hasn't happened again since I built ghc over.)
>>> And for some reason when I build ghc on OS X with debugging turned
>>> on, I need to explicit link in -lintl or I miss a symbol that
>>> libbfd  or libiberty is
>>> looking for. But that is probably neither here nor there.
>>> The assertion being violated is
>>>     ASSERT(frame < bottom);
>>> and it's not surprising that things rapidly go pear shaped if
>>> this  isn't true.
>>> Any ideas on how to proceed?  Just as a test, I built a compiler
>>> using GC.c from 6.4.1 but it quickly segfaulted.  I just had a hope
>>> that the significant changes may have been local to the GC.c file. 
>>> This is evidently not the case. Best Wishes,
>>> Greg