GHCi, version 6.10.1 crashes without message
Hi (and hello everybody), I read the FAQ, I searched down till Nov 2008, but did not find anything. I hope I didn't miss a FAQ or somewhat. (If so, please apologize!) My (freshly installed) GHCi 6.10.1 runs on Windows XP on Intel Dual Core. I used the .msi of the Webpage some two weeks ago. I got some strange program as example and tried out - and my ghci died quitly without any helping message. Here is the original programm: | f x y z = a + b*c + b + fun c | where a = x * y + z | b = c * fun x | c = a * b | fun x = x * x + 1 For testing out in previous of this posting, the following is the very same and had the same problem: | let f x y z = a + b*c + b + fun c where {a = x * y + z; b = c * fun x; c = a * b; fun x = x * x + 1} The query to die was "f 1 2 3". I tried with verbose ghci: | C:\...\ghc-6.10.1\bin>ghci -v | GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help | Glasgow Haskell Compiler, Version 6.10.1, for Haskell 98, stage 2 booted by GHC | version 6.8.3 | Using package config file: C:\...\GHC-61~1.1\package.conf | hiding package base-3.0.3.0 to avoid conflict with later version base-4.0.0.0 | wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 | wired-in package integer mapped to integer-0.1.0.0 | wired-in package base mapped to base-4.0.0.0 | wired-in package rts mapped to rts-1.0 | wired-in package haskell98 mapped to haskell98-1.0.1.0 | wired-in package syb mapped to syb-0.1.0.0 | wired-in package template-haskell mapped to template-haskell-2.3.0.0 | wired-in package dph-seq mapped to dph-seq-0.3 | wired-in package dph-par mapped to dph-par-0.3 | Hsc static flags: -static | Loading package ghc-prim ... linking ... done. | Loading package integer ... linking ... done. | Loading package base ... linking ... done. | Prelude> let f x y z = a + b*c + b + fun c where {a = x * y + z; b = c * fun x; | c = a * b; fun x = x * x + 1} | *** Parser: | *** Desugar: | *** Simplify: | *** CorePrep: | *** ByteCodeGen: | Prelude> f 1 2 3 | *** Parser: | *** Desugar: | *** Simplify: | *** CorePrep: | *** ByteCodeGen: | | C:\...\ghc-6.10.1\bin> I hope I could help finding some strange bug, killing 99% of your problems with Haskell, life and love, although I am very sure this one is only minor... ;-) MFG (With friendly regards) -- Heiko Studt <studt@fmi.uni-passau.de>
I reproduced the error on my setup (GHC 6.10.1 on WS2003), and received SEH exception 0xC00000FD, which is STATUS_STACK_OVERFLOW "A new guard page for the stack cannot be created". It looks like something is overflowing the OS stack or improperly bumping the guard page at the end of the allocated stack (which is used to extend the stack on demand). I could not get the crash to occur in GHC 6.8.3 via GHCi on the same system. Instead, evaluation blocks forever with 0% CPU, interruptable with CTRL+C. On Tue, Jan 13, 2009 at 10:15 AM, Heiko Studt <studt@fmi.uni-passau.de>wrote:
Hi (and hello everybody),
I read the FAQ, I searched down till Nov 2008, but did not find anything. I hope I didn't miss a FAQ or somewhat. (If so, please apologize!)
My (freshly installed) GHCi 6.10.1 runs on Windows XP on Intel Dual Core. I used the .msi of the Webpage some two weeks ago.
I got some strange program as example and tried out - and my ghci died quitly without any helping message.
Here is the original programm: | f x y z = a + b*c + b + fun c | where a = x * y + z | b = c * fun x | c = a * b | fun x = x * x + 1
For testing out in previous of this posting, the following is the very same and had the same problem: | let f x y z = a + b*c + b + fun c where {a = x * y + z; b = c * fun x; c = a * b; fun x = x * x + 1}
The query to die was "f 1 2 3".
I tried with verbose ghci:
| C:\...\ghc-6.10.1\bin>ghci -v | GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help | Glasgow Haskell Compiler, Version 6.10.1, for Haskell 98, stage 2 booted by GHC | version 6.8.3 | Using package config file: C:\...\GHC-61~1.1\package.conf | hiding package base-3.0.3.0 to avoid conflict with later version base-4.0.0.0 | wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 | wired-in package integer mapped to integer-0.1.0.0 | wired-in package base mapped to base-4.0.0.0 | wired-in package rts mapped to rts-1.0 | wired-in package haskell98 mapped to haskell98-1.0.1.0 | wired-in package syb mapped to syb-0.1.0.0 | wired-in package template-haskell mapped to template-haskell-2.3.0.0 | wired-in package dph-seq mapped to dph-seq-0.3 | wired-in package dph-par mapped to dph-par-0.3 | Hsc static flags: -static | Loading package ghc-prim ... linking ... done. | Loading package integer ... linking ... done. | Loading package base ... linking ... done. | Prelude> let f x y z = a + b*c + b + fun c where {a = x * y + z; b = c * fun x; | c = a * b; fun x = x * x + 1} | *** Parser: | *** Desugar: | *** Simplify: | *** CorePrep: | *** ByteCodeGen: | Prelude> f 1 2 3 | *** Parser: | *** Desugar: | *** Simplify: | *** CorePrep: | *** ByteCodeGen: | | C:\...\ghc-6.10.1\bin>
I hope I could help finding some strange bug, killing 99% of your problems with Haskell, life and love, although I am very sure this one is only minor... ;-)
MFG (With friendly regards)
-- Heiko Studt <studt@fmi.uni-passau.de>
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
* Heiko Studt <studt@fmi.uni-passau.de> [2009-01-13 16:15:51+0100]
Hi (and hello everybody),
I read the FAQ, I searched down till Nov 2008, but did not find anything. I hope I didn't miss a FAQ or somewhat. (If so, please apologize!)
My (freshly installed) GHCi 6.10.1 runs on Windows XP on Intel Dual Core. I used the .msi of the Webpage some two weeks ago.
I got some strange program as example and tried out - and my ghci died quitly without any helping message.
Here is the original programm: | f x y z = a + b*c + b + fun c | where a = x * y + z | b = c * fun x | c = a * b | fun x = x * x + 1
For testing out in previous of this posting, the following is the very same and had the same problem: | let f x y z = a + b*c + b + fun c where {a = x * y + z; b = c * fun x; c = a * b; fun x = x * x + 1}
The query to die was "f 1 2 3". [...]
Your program loops for the following reason: to compute f, you need to compute c to compute c, you need to compute b to compute b, you need to compute c again! Haskell cannot solve equations (or, at least, not formulated in this way), so it understands definition of f as the rules to compute things like a, b, c. No wonder evaluation of f never terminates. -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain
PPS: Why does your mailinglist not set the Reply-To header? @Roman Cheplyaka: Sorry for double mailing. Am 13.01.2009 schrieb Roman Cheplyaka:
| f x y z = a + b*c + b + fun c | where a = x * y + z | b = c * fun x | c = a * b | fun x = x * x + 1
The query to die was "f 1 2 3".
Your program loops for the following reason: to compute f, you need to compute c to compute c, you need to compute b to compute b, you need to compute c again!
Haskell cannot solve equations (or, at least, not formulated in this way), so it understands definition of f as the rules to compute things like a, b, c. No wonder evaluation of f never terminates.
The problem is not it does not terminate. It terminates. GHCi terminates inclusivly (maybe by simpathy? ;-)). As Chris Smith wrote it faults the stack. I tried to get the thing some smaller and therefor to the point, I should have done this before I assume: | let f = c where {c = c} at "f", | let f = f in f kills GHCi immidiatelly. | let f 0 = f 0 in f 0 simply does not terminate (as it should be). MFG (With friendly regards) Heiko Studt PS: Funny way for quitting with two keystroke. ;-) -- Heiko Studt <studt@fmi.uni-passau.de>
Heiko Studt wrote:
PPS: Why does your mailinglist not set the Reply-To header? @Roman Cheplyaka: Sorry for double mailing.
Am 13.01.2009 schrieb Roman Cheplyaka:
| f x y z = a + b*c + b + fun c | where a = x * y + z | b = c * fun x | c = a * b | fun x = x * x + 1
The query to die was "f 1 2 3".
Your program loops for the following reason: to compute f, you need to compute c to compute c, you need to compute b to compute b, you need to compute c again!
Haskell cannot solve equations (or, at least, not formulated in this way), so it understands definition of f as the rules to compute things like a, b, c. No wonder evaluation of f never terminates.
The problem is not it does not terminate. It terminates. GHCi terminates inclusivly (maybe by simpathy? ;-)). As Chris Smith wrote it faults the stack.
I tried to get the thing some smaller and therefor to the point, I should have done this before I assume:
| let f = c where {c = c}
at "f",
| let f = f in f
kills GHCi immidiatelly.
| let f 0 = f 0 in f 0
simply does not terminate (as it should be).
See http://hackage.haskell.org/trac/ghc/ticket/2783 and http://hackage.haskell.org/trac/ghc/ticket/2786 Cheers, Simon
participants (4)
-
Chris Smith -
Heiko Studt -
Roman Cheplyaka -
Simon Marlow