RE: ghc --make, recompilation problems? (was: GHC 6.2)
We're removing a lot of old/deprecated stuff in 6.2, so I want to be sure we haven't broken anything before doing the release. The best estimate I can give is 4-6 weeks, but it could be sooner if things settle down quickly.
talking about broken things: I've been reluctant to mention it so far, because I can't even give a reproducable example, and the problem only occurs on very large projects, so without a clue as to what might cause it, I certainly couldn't narrow down such an example, should I manage to pin down one.
there seems to be a problem in ghc --make's recompilation dependency checks, which means that recompilation might produce inconsistent executables. the usual effect is a problem-free rebuild, followed by inexplicable crashes of the executable. removing the .hi/.o files and calling ghc --make again reliably solves the problem, which is why I suspect recompilation-only dependency checks (type/class changes not propagated to dependent modules?).
sorry about this rather useless piece of information, but perhaps other people on this list have other parts of the puzzle, and it would be nice to get rid of this (haskell programs don't crash like this!-).
We have two known bugs in the recompilation checker. One is related to switching the optimisation level while developing a program with --make: the workaround is not to do this. The other bug is unfortunately rather more serious and doesn't have a workaround. Essentially it means that --make might not recompile as much of the program as it should, and you might end up with an inconsistent executable (which is likely to crash). Simon P.J. noticed the bug while revamping the front end recently, and we've verified that it can indeed lead to crashing programs. There isn't a simple fix, nor a workaround, although avoiding -O in conjunction with --make might help matters. 6.2 will have the bug (because the fix is in Simon P.J.'s rewrite of the front-end, which is scheduled for 6.4). That is unless we can think of a way to fix it that doesn't involve writing hundreds of lines of new code. Note that removing all the .o & .hi files and building from scratch will always result in a working program. The bug only affects recompilation after making changes to one or more modules in the program. This bug has basically been there ever since we had --make, and it has only been seen in the wild perhaps a handful of times, so it's arguably not a showstopper. However, it is rather disturbing. Cheers, Simon
The other bug is unfortunately rather more serious and doesn't have a workaround. Essentially it means that --make might not recompile as much of the program as it should, and you might end up with an inconsistent executable (which is likely to crash). Simon P.J. noticed the bug while revamping the front end recently, and we've verified that it can indeed lead to crashing programs. There isn't a simple fix, nor a workaround, although avoiding -O in conjunction with --make might help matters.
That sounds like what I've been seeing (no -O in use though, so that can't be it), thanks. Any indications as to what kinds of change are likely to fall into this gap? So far, I'm rather glad that crashes are the normal consequence - makes it easy to see whether the bug is mine or ghc's.
6.2 will have the bug (because the fix is in Simon P.J.'s rewrite of the front-end, which is scheduled for 6.4). That is unless we can think of a way to fix it that doesn't involve writing hundreds of lines of new code.
While you don't have a fix, could you please make ghc --make err on the safe side, i.e., if in doubt, re-compile? That would still be better than recompiling the whole project because something in the last few dozen modules went wrong (and a whole lot better than quickly constructing non-working code:). As a horrid hack-around, given that ghc --make from scratch gets things right, you could restart the dependency-ordered compilation sequence from the first change. Btw, could you give a pointer to the relevant module in cvs (unless it's unreadable)? Sounds like an interesting bug;-)
This bug has basically been there ever since we had --make, and it has only been seen in the wild perhaps a handful of times, so it's arguably not a showstopper. However, it is rather disturbing.
probably my projects were not wild enough until recently - do I get a trophy for spotting a rare bug in the wild, or do I have to send a photo?-) cheers, claus
participants (2)
-
Claus Reinke -
Simon Marlow