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
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
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
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
* Heiko Studt
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
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