debugging segfaults; any suggestions?
megacz at cs.berkeley.edu
Thu Apr 21 01:11:08 CEST 2011
"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
> 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?
More information about the Cvs-ghc