debugging segfaults; any suggestions?

[Adam Megacz]

"Edward Z. Yang" <ezyang at MIT.EDU> writes:
> Can you minimize the test-case into a minimal program that still segfaults?

Sadly, no; the extracted Haskell is difficult to read and very fragile
in the face of manual modifications.  It would be like editing STG code
by hand...


> Maybe you can reduce the Coq itself, or make the test case smaller.

I took this as far as I could; at a certain point I hit a local minimum
(which still a very large program).  It's really hard because what I
want to minimize is the Haskell code, but I have to do that by guessing
at what changes to make to the Coq code.  Unfortunately I'm not
optimistic about being able to get this down to a nice 5-line test case.

Another frustration has been laziness: the compiler only segfaults with
-ddump-core or -dcore-lint.  I was never completely sure if my changes
had eliminated the segfault or simply changed the execution path enough
that the thunk causing it was no longer getting forced.


> It seems pretty plausible that there might be a bug in the actual
> extraction code

Yeah, I don't want to start a finger-pointing game, but if I post this
to the coq-club list I'll probably just get the dual "pretty plausible
that there might be a bug in GHC" reply :)

Here's another thought: is it possible to compile the entirety of GHC as
GHCi bytecodes and run it under the interpreter?  Does the GHCi bytecode
keep enough type information that I could modify unsafeCoerce and have
it do a runtime type check?

  - a