Strange behavior in GHC-compiled code
Hi folks. I have a piece of Haskell code that's been laying around on my computer for about a year, and I recently decided to dust it off. The problem is that it used to work fine, but in the interim (in which I both upgraded OS versions/GHC versions and went from 32 bit to 64 bit) the code stopped working reliably. It tends to work OK for small data sets, but with larger data sets it exhibits one of three bad behaviors: 1) A segfault, 2) An "Error in array index" error, or 3) The following runtime error: internal error: evacuate: strange closure type 5060208 (GHC version 7.0.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted It complies OK, although with optimization turned on it gives me a "has one call pattern, but the limit is 0" error, but my understanding is that this shouldn't really be an issue. I'd like to figure out what this issue is, but while I understand a bit about the language itself, with my knowledge of GHC and the way it works I don't really know where to begin. (The strange non-deterministic nature of the problem makes me wonder if it could be something not related to Haskell, such as a hardware or memory error. Is this possible or likely?) Any guidance/pointers would be very much appreciated. Thanks. -Mark
Unless you show us the code, any answers will be guesses in the dark. Does your program use unsafePerformIO unsafely perhaps? Or a version of a library that happens to have a known bug?
On 25/05/2012, at 14:33, Mark Conway Wirt
I have a piece of Haskell code that's been laying around on my computer for about a year, and I recently decided to dust it off.
The problem is that it used to work fine, but in the interim (in which I both upgraded OS versions/GHC versions and went from 32 bit to 64 bit) the code stopped working reliably. [...]
Any guidance/pointers would be very much appreciated.
On Fri, May 25, 2012 at 05:53:52PM +0100, Malcolm Wallace wrote:
Unless you show us the code, any answers will be guesses in the dark. Does your program use unsafePerformIO unsafely perhaps? Or a version of a library that happens to have a known bug?
No unsafePerformIO's or IOrefs or the like. The code itself is straight-forward (I think). It uses no external libraries -- just Data and System as bundled. One of the problems is that I don't know where in the code the problem may be arising -- the code is about 1200 lines, so it's not really practical to post it! (I'm starting to think that this issue may not be related to Haskell, as the problem arises so inconsistently -- sometimes the code runs, sometimes it bombs out early. I haven't rebooted the computer in a month or so, maybe it's time.) I guess what I'm asking is: what strategies should I be employing for debugging the problem? If the problem is with an array, for example, "error in array index" doesn't give me much to go on if I don't know which array may be the problem. Should I be trying to reproduce the problem in ghci's debugger, for example? Will that give me more context? --Mark
Hi, Am Freitag, den 25.05.2012, 14:26 -0400 schrieb Mark Conway Wirt:
(I'm starting to think that this issue may not be related to Haskell, as the problem arises so inconsistently -- sometimes the code runs, sometimes it bombs out early. I haven't rebooted the computer in a month or so, maybe it's time.)
in that case I suggest you run a memory checker, e.g. memtest86, and see if it find some hardware bugs. Or run the program on another machine and see if the problem appears there as well. Greetings, Joachim -- Joachim "nomeata" Breitner mail@joachim-breitner.de | nomeata@debian.org | GPG: 0x4743206C xmpp: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/
On Fri, May 25, 2012 at 11:45:41PM +0200, Joachim Breitner wrote:
in that case I suggest you run a memory checker, e.g. memtest86, and see if it find some hardware bugs. Or run the program on another machine and see if the problem appears there as well.
Hey Joachim, thanks for the reference to memtest86. Memory was in fact the problem (one of the SODMM modules had errors). Replaced the memory and everything is working. Thanks again. --Mark
participants (3)
-
Joachim Breitner -
Malcolm Wallace -
Mark Conway Wirt