Heap profiling dumped NULs
Hi, I can't reproduce it, but on one occasion running profiling with -hd, I got corrupt .hp output, with a large block of NULs in an otherwise normal output (The output is large, but I can make it available if anybody wants it). Rerunning the exact same command line produced a normal .hp. Just in case you'd like to know. (GHC 6.0 from RPM on RH 9) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
interactive co-recursion
I've no idea if the following is supposed to work, but the message
tells me to report it, so here it is. Happens for all attempts to
define co-recursive functions, this is just the simplest example.
Prelude> let { f = g ; g = f}
ghc-6.0: panic! (the `impossible' happened, GHC version 6.0):
getLinkDeps No iface for []DataziTuple
Please report it as a compiler bug to [EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Odd GHCi behavior
Andy Moran <[EMAIL PROTECTED]> writes: > Skipping Util.List( ../../libraries/Util/List.hs, > ../../libraries/Util/List.o ) > ... > Failed to load interface for `Util.List': > Doing a big old clean, --make, and then GHCi solved the problem. But what > could cause this kind of behavior? (I can't reproduce it, sorry.) Something similar has occasionally happened to me when I've interrupted (^C) a build. Presumably, the compiler gets around to touching the relevant file(s), but stops before it is able to finish them, and doesn't clean up. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: internal error: eval_thunk_selector: strange selectee 29
"Simon Marlow" <[EMAIL PROTECTED]> writes: > We know of two recompilation bugs in 5.04.x & 6.0.x, both of which can > result a broken binary after making a change to a module in the program > and recompiling with --make (or in GHCi). > The first is when you switch from using -O to compiling without -O. If > you do this, recompile the whole program from scratch. It could well be something like this, since I experiemented with different optimizations (since the combination of profiling and optimization has been fragile before). > The second we only discovered last week, and it turns out that the > current recompilation system forgets about some dependencies that it > shouldn't, and consequently will fail to recompile some things. I don't > have a workaround yet, apart from avoiding --make. --make is just too pleasant not to be used. I can always clean out things in case of weird errors. Would you like me to submit subsequent reports if I encounter further problems? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
internal error: eval_thunk_selector: strange selectee 29
(Apologies for the repeated message, the moderator seems to be out at the moment, so I just subscribed to the list and resent it, this time with a bit more information) Trying to run profiling (+RTS -p -RTS), I get: xsactp: internal error: eval_thunk_selector: strange selectee 29 Please report this as a bug to [EMAIL PROTECTED], or http://www.sourceforge.net/projects/ghc/ Command exited with non-zero status 254 Compilation was done with: -fglasgow-exts -package data -fno-warn-unused-matches -fno-warn-unused-binds -W -O2 -prof -auto-all -hisuf p.hi -osuf p.o Recompilation without the -O2 seems to have eliminated the problem, although I'm still waiting for the profiling run to finish. This is with GHC 6.0, on Red Hat 9. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: internal error: eval_thunk_selector: strange selectee 29
"Simon Marlow" <[EMAIL PROTECTED]> writes: >> There is something really fishy going on; I checked out the same code >> in a different directory, and built it in the same way, without >> getting the same behaviour. > Hmm. Profiling isn't deterministic though, because heap samples happen > based on a timer interrupt, so you might get different results if you > run it multiple times. >> I'm not quite sure what kind of confusion that led to the error (or >> the fact that my run times suddenly were tripled); possibly some old >> .o or .hi file got copied in by mistake? > Possibly, or possibly a recompilation bug (are you using --make?). Yes, I am. I got the error several times, but when I cleaned everything up, it seems to have gone away -- as did the tripled running times (and yes, they were user/system times, not just wall clock). Very puzzling. Unfortunately, a 'make clean' removed all the evidence -- if I stumble over it again, I'll make a copy first. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: internal error: eval_thunk_selector: strange selectee 29
"Simon Marlow" <[EMAIL PROTECTED]> writes: > Can you send the code, or is it too large? Both of the above. :-) There is something really fishy going on; I checked out the same code in a different directory, and built it in the same way, without getting the same behaviour. I'm not quite sure what kind of confusion that led to the error (or the fact that my run times suddenly were tripled); possibly some old .o or .hi file got copied in by mistake? Compiling with -optl-static should only affect the linking stage, shouldn't it? (I.e. the *.o etc. files should be identical?) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
