hugs segmentation fault
Hi, I am new to haskell, but otherwise experienced in programming languages. My first attempt at Haskell was this (on a Linux Debian) session with hugs: Type :? for help Prelude> :version -- Hugs Version November 2003 Prelude> let p = 1 : [2 * x | x <- p, x < 1] in p [1Segmentation fault Is it the norm for hugs to dump core like this? Or was I just very lucky to discover a bug? Best regards, Andrej
On 2004-10-29 at 00:45+0200 Andrej Bauer wrote:
Hi,
I am new to haskell, but otherwise experienced in programming languages. My first attempt at Haskell was this (on a Linux Debian) session with hugs:
Type :? for help Prelude> :version -- Hugs Version November 2003 Prelude> let p = 1 : [2 * x | x <- p, x < 1] in p [1Segmentation fault
Is it the norm for hugs to dump core like this? Or was I just very lucky to discover a bug?
UNlucky. There's a bug in your programme in that it goes into an infinite loop consuming something (stack probably), and it happens that hugs doesn't correctly check for its exhaustion. (I'd call that a bug too) In ghci you get: [1*** Exception: <<loop>> which is better. -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
Jon Fairbairn wrote:
In ghci you get:
[1*** Exception: <<loop>>
which is better.
Not much better, though: in my experience this particular exception leaves ghci in a very peculiar state, and it's usually necessary to quit and restart it before it will work again. Is it coincidence that both Hugs and GHCi have trouble handling dependency loops, or is it a very difficult problem that both have given up on solving? -- Ben
On 2004-10-29 at 00:03BST Ben Rudiak-Gould wrote:
Jon Fairbairn wrote:
In ghci you get:
[1*** Exception: <<loop>>
which is better.
Not much better, though: in my experience this particular exception leaves ghci in a very peculiar state, and it's usually necessary to quit and restart it before it will work again.
I don't think I've seen such a problem (maybe I so rarely make that type of mistake?;-). What version? What are the symptoms of this not working of which you speak? It seems OK in ghci 6.2.1
Is it coincidence that both Hugs and GHCi have trouble handling dependency loops, or is it a very difficult problem that both have given up on solving?
It's not difficult per se, but it may be difficult to do without performance implications, and compiler hackers are always terribly protective of their performance... Jón -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
Jon Fairbairn wrote:
On 2004-10-29 at 00:03BST Ben Rudiak-Gould wrote:
Not much better, though: in my experience this particular exception leaves ghci in a very peculiar state, and it's usually necessary to quit and restart it before it will work again.
I don't think I've seen such a problem (maybe I so rarely make that type of mistake?;-). What version? What are the symptoms of this not working of which you speak? It seems OK in ghci 6.2.1
Well, here's a sample session I recorded just now: C:\>\ghc\ghc-6.2.1\bin\ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.2.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Prelude> let p = 1 : [2 * x | x <- p, x < 1] in p [1*** Exception: <<loop>> Prelude> 123 Fail: thread blocked indefinitely C:\> Does this only happen to me? -- Ben
On 29-Oct-2004, Ben Rudiak-Gould
Jon Fairbairn wrote:
On 2004-10-29 at 00:03BST Ben Rudiak-Gould wrote:
Not much better, though: in my experience this particular exception leaves ghci in a very peculiar state, and it's usually necessary to quit and restart it before it will work again.
I don't think I've seen such a problem (maybe I so rarely make that type of mistake?;-). What version? What are the symptoms of this not working of which you speak? It seems OK in ghci 6.2.1
We ran into a related problem recently. I think the problem may only show up on Windows, not on Linux. The problem is that when a loop occurs, ghc's garbage collection detects that the standard I/O handles for stdin/stdout/stderr can no longer be referenced and finalizes them, *before* detecting the loop and throwing an exception. Subsequent code may then attempt to use these already-finalized standard I/O handles. A possible work-around is to create stable pointers to those handles. But I'm not sure whether this is the same problem that you are experiencing. -- Fergus J. Henderson | "I have always known that the pursuit Galois Connections, Inc. | of excellence is a lethal habit" Phone: +1 503 626 6616 | -- the last words of T. S. Garp.
On Thu, Oct 28, 2004 at 05:51:18PM -0700, Fergus Henderson wrote:
We ran into a related problem recently. I think the problem may only show up on Windows, not on Linux. The problem is that when a loop occurs, ghc's garbage collection detects that the standard I/O handles for stdin/stdout/stderr can no longer be referenced and finalizes them, *before* detecting the loop and throwing an exception. Subsequent code may then attempt to use these already-finalized standard I/O handles. A possible work-around is to create stable pointers to those handles. But I'm not sure whether this is the same problem that you are experiencing.
I've seen a couple of oddities with the Windows Nov 2003 hugs build some students have run into on EfNet #haskell but the users were all too naive to get adequate descriptions out of. The first of these had to do with qualified names, the second had to do with some explicitly-typed top-level expressions. I don't have access to Windows systems to try to reproduce these on my own. The "issues" weren't crashes, they were merely behavior differing from ghci et al in the former case and with the UNIX builds in the latter. I don't have adequate specifics myself, so if someone could chase these down for me, I'd be much obliged. -- wli
On 2004-10-29 at 00:50BST Ben Rudiak-Gould wrote:
Jon Fairbairn wrote:
On 2004-10-29 at 00:03BST Ben Rudiak-Gould wrote:
Not much better, though: in my experience this particular exception leaves ghci in a very peculiar state, and it's usually necessary to quit and restart it before it will work again.
I don't think I've seen such a problem (maybe I so rarely make that type of mistake?;-). What version? What are the symptoms of this not working of which you speak? It seems OK in ghci 6.2.1
Well, here's a sample session I recorded just now:
C:\>\ghc\ghc-6.2.1\bin\ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.2.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help.
Loading package base ... linking ... done. Prelude> let p = 1 : [2 * x | x <- p, x < 1] in p [1*** Exception: <<loop>> Prelude> 123
Fail: thread blocked indefinitely
C:\>
Does this only happen to me?
I'm using Linux, you Windows. I suspect there's a hint there. Has this been reported to Glasgow Haskell bugs? (cc'd) -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
"Jon Fairbairn"
On 2004-10-29 at 00:50BST Ben Rudiak-Gould wrote:
Jon Fairbairn wrote:
....
Well, here's a sample session I recorded just now:
C:\>\ghc\ghc-6.2.1\bin\ghci
....
Prelude> let p = 1 : [2 * x | x <- p, x < 1] in p [1*** Exception: <<loop>> Prelude> 123
Fail: thread blocked indefinitely
C:\>
Does this only happen to me?
I'm using Linux, you Windows. I suspect there's a hint there. Has this been reported to Glasgow Haskell bugs? (cc'd)
Plenty of times, but maybe not that particular manifestation of the problem. Fixed in 6.2.2 --sigbjorn
participants (6)
-
Andrej Bauer -
Ben Rudiak-Gould -
Fergus Henderson -
Jon Fairbairn -
Sigbjorn Finne -
William Lee Irwin III