Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation ---+ Reporter: pturnbull | Owner: tibbe Type: bug | Status: new Priority: high| Milestone: 7.6.2 Component: GHCi| Version: 6.12.3 Keywords: MVar| Os: MacOS X Architecture: x86_64 (amd64) | Failure: GHCi crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by tibbe): * owner: igloo => tibbe -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7208: ghci panic: nameModule show{tv a9W}
#7208: ghci panic: nameModule show{tv a9W}
--+-
Reporter: felipe zapata |Owner:
Type: bug| Status: closed
Priority: normal |Component: GHCi
Version: 7.4.1 | Resolution: duplicate
Keywords: ghci panic nameModule | Os: Linux
Architecture: x86| Failure: GHCi crash
Testcase: |Blockedby:
Blocking: | Related:
--+-
Changes (by guest):
* status: new => closed
* resolution: => duplicate
Comment:
It's already fixed then.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7208#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7208: ghci panic: nameModule show{tv a9W}
#7208: ghci panic: nameModule show{tv a9W}
---+
Reporter: felipe zapata | Owner:
Type: bug| Status: new
Priority: normal | Component: GHCi
Version: 7.4.1 | Keywords: ghci panic nameModule
Os: Linux | Architecture: x86
Failure: GHCi crash | Testcase:
Blockedby: | Blocking:
Related: |
---+
Comment(by guest):
Please post the code. If you have an invalid "deriving" clause (starting
with lowercase letter), it is already fixed in GHC 7.6.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7208#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #7208: ghci panic: nameModule show{tv a9W}
#7208: ghci panic: nameModule show{tv a9W}
---+
Reporter: felipe zapata | Owner:
Type: bug| Status: new
Priority: normal | Component: GHCi
Version: 7.4.1 | Keywords: ghci panic nameModule
Os: Linux | Architecture: x86
Failure: GHCi crash | Testcase:
Blockedby: | Blocking:
Related: |
---+
Comment(by parcs):
This looks like a duplicate of #5961.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7208#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #7208: ghci panic: nameModule show{tv a9W}
#7208: ghci panic: nameModule show{tv a9W}
---+
Reporter: felipe zapata | Owner:
Type: bug| Status: new
Priority: normal | Component: GHCi
Version: 7.4.1 | Keywords: ghci panic nameModule
Os: Linux | Architecture: x86
Failure: GHCi crash | Testcase:
Blockedby: | Blocking:
Related: |
---+
I was Editing some modules of my project, then I just tried
> ghci Mymodule.hs and then I got the following error:
[1 of 6] Compiling GlobalTypes ( GlobalTypes.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 7.4.1 for x86_64-unknown-linux):
nameModule show{tv a9W}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7208>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation ---+ Reporter: pturnbull | Owner: igloo Type: bug | Status: new Priority: high| Milestone: 7.4.3 Component: GHCi| Version: 6.12.3 Keywords: MVar| Os: MacOS X Architecture: x86_64 (amd64) | Failure: GHCi crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by mihai.maruseac): * cc: mihai.maruseac@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation ---+ Reporter: pturnbull | Owner: igloo Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: GHCi| Version: 6.12.3 Keywords: MVar| Os: MacOS X Architecture: x86_64 (amd64) | Failure: GHCi crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by igloo): * owner: tibbe => igloo -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation ---+ Reporter: pturnbull | Owner: tibbe Type: bug | Status: new Priority: high| Milestone: 7.4.2 Component: GHCi| Version: 6.12.3 Keywords: MVar| Os: MacOS X Architecture: x86_64 (amd64) | Failure: GHCi crash Difficulty: Unknown |Testcase: Blockedby: |Blocking: Related: | ---+ Changes (by igloo): * difficulty: => Unknown * milestone: 7.4.1 => 7.4.2 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation
---+
Reporter: pturnbull |Owner: tibbe
Type: bug | Status: new
Priority: high|Milestone: 7.4.1
Component: GHCi| Version: 6.12.3
Keywords: MVar| Testcase:
Blockedby: | Difficulty:
Os: MacOS X | Blocking:
Architecture: x86_64 (amd64) | Failure: GHCi crash
---+
Changes (by simonmar):
* cc: bos (added)
* owner: igloo => tibbe
Comment:
There's an even simpler example:
{{{
main :: IO ()
main = do putStrLn "Waiting for input"
getChar
putStrLn "There's some input"
}}}
reproduce by:
* run the program (on OS X)
* suspend with `^Z`
* resume with `fg`
* Now hit `^C`: observe that nothing happens
* (another `^C` kills the program)
Without the `^Z/fg` combination first, the `^C` signal works as it should.
What appears to be happening is this:
* the main thread is blocked in `threadWaitRead` on FD 0
* on resumption, `threadWaitRead` returns
* thinking that there is data to be read, we now call `read()` (this is
in `GHC.IO.FD.readRawBufferPtr`)
* there is actually no data to read, so `read()` blocks
I believe the bug is that `threadWaitRead` returns when it shouldn't, so
I'm punting this to the IO manager maintainers. Johan/Bryan?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:22>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation ---+ Reporter: pturnbull |Owner: igloo Type: bug | Status: new Priority: high|Milestone: 7.4.1 Component: GHCi| Version: 6.12.3 Keywords: MVar| Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: GHCi crash ---+ Comment(by simonmar): See also #5565 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation ---+ Reporter: pturnbull |Owner: igloo Type: bug | Status: new Priority: high|Milestone: 7.4.1 Component: GHCi| Version: 6.12.3 Keywords: MVar| Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: GHCi crash ---+ Comment(by igloo): I have a hunch the problem will be around `rts/posix/Signals.c` `sigtstp_handler` and `set_sigtstp_action`. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation
---+
Reporter: pturnbull |Owner: igloo
Type: bug | Status: new
Priority: high|Milestone: 7.4.1
Component: GHCi| Version: 6.12.3
Keywords: MVar| Testcase:
Blockedby: | Difficulty:
Os: MacOS X | Blocking:
Architecture: x86_64 (amd64) | Failure: GHCi crash
---+
Comment(by igloo):
With `z.hs`:
{{{
import Control.Concurrent
import Control.Exception
import Prelude hiding (catch)
import System.IO
main :: IO ()
main = do mv <- newEmptyMVar
tid <- forkIO $ otherThread mv
takeMVar mv
`catch` \e ->
do putStrLn ("Got exception: " ++ show (e :: SomeException))
putStrLn "Killing thread"
killThread tid
putStrLn "Killed thread"
otherThread :: MVar () -> IO ()
otherThread mv = do putStrLn "Waiting for input"
_ <- hWaitForInput stdin (-1)
putStrLn "There's some input"
putMVar mv ()
}}}
if we compile with HEAD on OS X (x86 or x86_64) with the threaded RTS:
{{{
ghc --make z -threaded
}}}
then run it, `^Z` it, `fg` it, then `^C` it, then the `killThread` blocks:
{{{
$ ./z
Waiting for input
^Z
[1]+ Stopped ./z
212:examples ian$ fg
./z
^CGot exception: user interrupt
Killing thread
}}}
Another `^C` silently terminates the program.
It doesn't happen if:
* We don't do the `^Z`/`fg`
* We don't use the threaded RTS
* It is run on Linux
So now the question is, why does it happen and how do we fix it?
(I believe Haskeline doing something like the above, mixed in with using
an MVar, is the underlying case of the GHCi bug)
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:19>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation ---+ Reporter: pturnbull |Owner: igloo Type: bug | Status: new Priority: high|Milestone: 7.4.1 Component: GHCi| Version: 6.12.3 Keywords: MVar| Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: GHCi crash ---+ Changes (by igloo): * owner: => igloo -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation ---+ Reporter: pturnbull |Owner: Type: bug | Status: new Priority: high|Milestone: 7.4.1 Component: GHCi| Version: 6.12.3 Keywords: MVar| Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: GHCi crash ---+ Changes (by igloo): * milestone: 7.2.1 => 7.4.1 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation ---+ Reporter: pturnbull |Owner: Type: bug | Status: new Priority: high|Milestone: 7.2.1 Component: GHCi| Version: 6.12.3 Keywords: MVar| Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: GHCi crash ---+ Changes (by simonmar): * priority: normal => high Comment: More reports of this bug: #5191 #5368 (also #5029 and #4000, but these had no info) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation ---+ Reporter: pturnbull |Owner: Type: bug | Status: new Priority: normal |Milestone: 7.2.1 Component: GHCi| Version: 6.12.3 Keywords: MVar| Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: GHCi crash ---+ Comment(by modchan): Issued `fst ((1, 'a'),"foo")`, GHCi answered correctly, but then crashed out with "thread blocked indefinitely in an MVar operation". Unfortunately, I cannot reproduce this. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation ---+ Reporter: pturnbull |Owner: Type: bug | Status: new Priority: normal |Milestone: 7.2.1 Component: GHCi| Version: 6.12.3 Keywords: MVar| Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: GHCi crash ---+ Changes (by modchan): * cc: malicious.wizard@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5268: ghci panic in ByteCodeGen.schemeE: unhandled case
#5268: ghci panic in ByteCodeGen.schemeE: unhandled case
---+
Reporter: patrikja | Owner:
Type: bug | Status: closed
Priority: normal| Milestone:
Component: Compiler |Version: 7.1
Resolution: fixed | Keywords:
Testcase:| Blockedby:
Difficulty:| Os: Unknown/Multiple
Blocking:| Architecture: Unknown/Multiple
Failure: None/Unknown |
---+
Changes (by simonpj):
* status: new => closed
* resolution: => fixed
Comment:
Thanks. Fixed by
{{{
commit 09d83049b2c5a6a9b44e70f19ae09f9cb08b3da2
Author: Simon Peyton Jones
Date: Thu Jun 23 14:28:50 2011 +0100
Fix Trac #5268: missing case for bytecode generation involving
coercions
compiler/ghci/ByteCodeGen.lhs | 40
++--
1 files changed, 18 insertions(+), 22 deletions(-)
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5268#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5268: ghci panic in ByteCodeGen.schemeE: unhandled case
#5268: ghci panic in ByteCodeGen.schemeE: unhandled case -+-- Reporter: patrikja |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by simonpj): Aha! Good. I'm fixing the panic now. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5268#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5268: ghci panic in ByteCodeGen.schemeE: unhandled case
#5268: ghci panic in ByteCodeGen.schemeE: unhandled case -+-- Reporter: patrikja |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by patrikja): Replying to [comment:2 simonpj]: > Very quick! I know what to do about the GHCi thing, but maybe the type error is correct?! > > It's a big program. Can you write down the argument that says the type error is wrong? > > Thx > > S I have no good reason to believe that type error is wrong - the code is in a state of flux. So the bug report is only about the panic - the type error part was just to help debugging (I found it strange that ghci did not report the same error). /Patrik -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5268#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5268: ghci panic in ByteCodeGen.schemeE: unhandled case
#5268: ghci panic in ByteCodeGen.schemeE: unhandled case -+-- Reporter: patrikja |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 7.1 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by simonpj): Very quick! I know what to do about the GHCi thing, but maybe the type error is correct?! It's a big program. Can you write down the argument that says the type error is wrong? Thx S -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5268#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #5268: ghci panic in ByteCodeGen.schemeE: unhandled case
#5268: ghci panic in ByteCodeGen.schemeE: unhandled case
-+--
Reporter: patrikja |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 7.1
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Description changed by simonpj:
Old description:
> To reproduce:
> # install ghc from git HEAD 20110622
> tar -zxf MonadicSystems-0.3.0.tar.gz
> cd MonadicSystems-0.3.0/
> cabal configure
> cabal build
> ghci MonadicSystems/Example/InputTransition3
>
> Resulting panic is below.
>
> Note that ghc reports a type error (no panic), while ghci panics.
>
> I attach a snapshot of the code (which is not finished yet, but I thought
> you may have use for the report).
>
> /Patrik
>
> patrikj@dela:~/tmp/MonadicSystems-0.3.0$ ghci
> MonadicSystems/Example/InputTransition3
> GHCi, version 7.1.20110622: http://www.haskell.org/ghc/ :? for help
> Loading package ghc-prim ... linking ... done.
> Loading package integer-gmp ... linking ... done.
> Loading package base ... linking ... done.
> Loading package ffi-1.0 ... linking ... done.
> [ 1 of 12] Compiling MonadicSystems.ConstructorType (
> MonadicSystems/ConstructorType.hs, interpreted )
> [ 2 of 12] Compiling MonadicSystems.ConstructorType.Instances.Identity (
> MonadicSystems/ConstructorType/Instances/Identity.hs, interpreted )
> [ 3 of 12] Compiling MonadicSystems.Function2 (
> MonadicSystems/Function2.hs, interpreted )
> [ 4 of 12] Compiling MonadicSystems.Function (
> MonadicSystems/Function.hs, interpreted )
> [ 5 of 12] Compiling MonadicSystems.Function.Instances.ToFunction (
> MonadicSystems/Function/Instances/ToFunction.hs, interpreted )
> [ 6 of 12] Compiling MonadicSystems.Functor ( MonadicSystems/Functor.hs,
> interpreted )
> [ 7 of 12] Compiling MonadicSystems.Functor.Instances.Identity (
> MonadicSystems/Functor/Instances/Identity.hs, interpreted )
> [ 8 of 12] Compiling MonadicSystems.Monad ( MonadicSystems/Monad.hs,
> interpreted )
> [ 9 of 12] Compiling MonadicSystems.Monad.Instances.Identity (
> MonadicSystems/Monad/Instances/Identity.hs, interpreted )
> [10 of 12] Compiling MonadicSystems.Coalgebra (
> MonadicSystems/Coalgebra.hs, interpreted )
> ghc: panic! (the 'impossible' happened)
> (GHC version 7.1.20110622 for x86_64-unknown-linux):
> ByteCodeGen.schemeE: unhandled case CO tpl_B4{v} [lid]
>
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
> patrikj@dela:~/tmp/MonadicSystems-0.3.0$ ghc
> MonadicSystems/Example/InputTransition3
> [ 1 of 12] Compiling MonadicSystems.ConstructorType (
> MonadicSystems/ConstructorType.hs, MonadicSystems/ConstructorType.o )
> [ 2 of 12] Compiling MonadicSystems.Function (
> MonadicSystems/Function.hs, MonadicSystems/Function.o )
> [ 3 of 12] Compiling MonadicSystems.Function.Instances.ToFunction (
> MonadicSystems/Function/Instances/ToFunction.hs,
> MonadicSystems/Function/Instances/ToFunction.o )
> [ 4 of 12] Compiling MonadicSystems.Functor ( MonadicSystems/Functor.hs,
> MonadicSystems/Functor.o )
> [ 5 of 12] Compiling MonadicSystems.Monad ( MonadicSystems/Monad.hs,
> MonadicSystems/Monad.o )
> [ 6 of 12] Compiling MonadicSystems.Function2 (
> MonadicSystems/Function2.hs, MonadicSystems/Function2.o )
> [ 7 of 12] Compiling MonadicSystems.Coalgebra (
> MonadicSystems/Coalgebra.hs, MonadicSystems/Coalgebra.o )
> [ 8 of 12] Compiling MonadicSystems.ConstructorType.Instances.Identity (
> MonadicSystems/ConstructorType/Instances/Identity.hs,
> MonadicSystems/ConstructorType/Instances/Identity.o )
> [ 9 of 12] Compiling MonadicSystems.Monad.Instances.Identity (
> MonadicSystems/Monad/Instances/Identity.hs,
> MonadicSystems/Monad/Instances/Identity.o )
> [10 of 12] Compiling MonadicSystems.Functor.Instances.Identity (
> MonadicSystems/Functor/Instances/Identity.hs,
> MonadicSystems/Functor/Instances/Identity.o )
> [11 of 12] Compiling MonadicSystems.MonadicCoalgebra (
> MonadicSystems/MonadicCoalgebra.hs, MonadicSystems/MonadicCoalgebra.o )
> [12 of 12] Compiling MonadicSystems.Example.InputTransition3 (
> MonadicSystems/Example/InputTransition3.hs,
> MonadicSystems/Example/InputTransition3.o )
>
> MonadicSystems/Example/InputTransition3.hs:18:10:
> Couldn't match type `Int'
>
[GHC] #5268: ghci panic in ByteCodeGen.schemeE: unhandled case
#5268: ghci panic in ByteCodeGen.schemeE: unhandled case
-+--
Reporter: patrikja | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 7.1 |Keywords:
Testcase:| Blockedby:
Os: Unknown/Multiple |Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
To reproduce:
# install ghc from git HEAD 20110622
tar -zxf MonadicSystems-0.3.0.tar.gz
cd MonadicSystems-0.3.0/
cabal configure
cabal build
ghci MonadicSystems/Example/InputTransition3
Resulting panic is below.
Note that ghc reports a type error (no panic), while ghci panics.
I attach a snapshot of the code (which is not finished yet, but I thought
you may have use for the report).
/Patrik
patrikj@dela:~/tmp/MonadicSystems-0.3.0$ ghci
MonadicSystems/Example/InputTransition3
GHCi, version 7.1.20110622: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
[ 1 of 12] Compiling MonadicSystems.ConstructorType (
MonadicSystems/ConstructorType.hs, interpreted )
[ 2 of 12] Compiling MonadicSystems.ConstructorType.Instances.Identity (
MonadicSystems/ConstructorType/Instances/Identity.hs, interpreted )
[ 3 of 12] Compiling MonadicSystems.Function2 (
MonadicSystems/Function2.hs, interpreted )
[ 4 of 12] Compiling MonadicSystems.Function ( MonadicSystems/Function.hs,
interpreted )
[ 5 of 12] Compiling MonadicSystems.Function.Instances.ToFunction (
MonadicSystems/Function/Instances/ToFunction.hs, interpreted )
[ 6 of 12] Compiling MonadicSystems.Functor ( MonadicSystems/Functor.hs,
interpreted )
[ 7 of 12] Compiling MonadicSystems.Functor.Instances.Identity (
MonadicSystems/Functor/Instances/Identity.hs, interpreted )
[ 8 of 12] Compiling MonadicSystems.Monad ( MonadicSystems/Monad.hs,
interpreted )
[ 9 of 12] Compiling MonadicSystems.Monad.Instances.Identity (
MonadicSystems/Monad/Instances/Identity.hs, interpreted )
[10 of 12] Compiling MonadicSystems.Coalgebra (
MonadicSystems/Coalgebra.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 7.1.20110622 for x86_64-unknown-linux):
ByteCodeGen.schemeE: unhandled case CO tpl_B4{v} [lid]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
patrikj@dela:~/tmp/MonadicSystems-0.3.0$ ghc
MonadicSystems/Example/InputTransition3
[ 1 of 12] Compiling MonadicSystems.ConstructorType (
MonadicSystems/ConstructorType.hs, MonadicSystems/ConstructorType.o )
[ 2 of 12] Compiling MonadicSystems.Function ( MonadicSystems/Function.hs,
MonadicSystems/Function.o )
[ 3 of 12] Compiling MonadicSystems.Function.Instances.ToFunction (
MonadicSystems/Function/Instances/ToFunction.hs,
MonadicSystems/Function/Instances/ToFunction.o )
[ 4 of 12] Compiling MonadicSystems.Functor ( MonadicSystems/Functor.hs,
MonadicSystems/Functor.o )
[ 5 of 12] Compiling MonadicSystems.Monad ( MonadicSystems/Monad.hs,
MonadicSystems/Monad.o )
[ 6 of 12] Compiling MonadicSystems.Function2 (
MonadicSystems/Function2.hs, MonadicSystems/Function2.o )
[ 7 of 12] Compiling MonadicSystems.Coalgebra (
MonadicSystems/Coalgebra.hs, MonadicSystems/Coalgebra.o )
[ 8 of 12] Compiling MonadicSystems.ConstructorType.Instances.Identity (
MonadicSystems/ConstructorType/Instances/Identity.hs,
MonadicSystems/ConstructorType/Instances/Identity.o )
[ 9 of 12] Compiling MonadicSystems.Monad.Instances.Identity (
MonadicSystems/Monad/Instances/Identity.hs,
MonadicSystems/Monad/Instances/Identity.o )
[10 of 12] Compiling MonadicSystems.Functor.Instances.Identity (
MonadicSystems/Functor/Instances/Identity.hs,
MonadicSystems/Functor/Instances/Identity.o )
[11 of 12] Compiling MonadicSystems.MonadicCoalgebra (
MonadicSystems/MonadicCoalgebra.hs, MonadicSystems/MonadicCoalgebra.o )
[12 of 12] Compiling MonadicSystems.Example.InputTransition3 (
MonadicSystems/Example/InputTransition3.hs,
MonadicSystems/Example/InputTransition3.o )
MonadicSystems/Example/InputTransition3.hs:18:10:
Couldn't match type `Int'
with `MS.McA.FunctorTag InputTransition3
MS.McA.:@ MS.McA.Codomain InputTransition3'
In the instance declaration for `MS.McA.CoalgebraWithInput
InputTransition3'
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5268>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation ---+ Reporter: pturnbull |Owner: Type: bug | Status: new Priority: normal |Milestone: 7.2.1 Component: GHCi| Version: 6.12.3 Keywords: MVar| Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: GHCi crash ---+ Comment(by simonmar): Also reported in #5191 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation ---+ Reporter: pturnbull |Owner: Type: bug | Status: new Priority: normal |Milestone: 7.2.1 Component: GHCi| Version: 6.12.3 Keywords: MVar| Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: GHCi crash ---+ Changes (by fryguybob): * cc: fryguybob@… (added) Comment: I've experienced the behavior from the last reporter on Windows with 7.0.2. For a while I've tried to get something repeatable to no avail. When it is happening it seems to happen fairly frequently. Some days I never run into it. I have never had it happen with HEAD which makes me suspect that #4531 fixed it. Some things that have triggered it for me: * Typing `q` instead of `:q` (other things not in scope too). * Hitting tab then `y` to display all. * Pasting a long line. When it fails in this case I have been pasting a `let` expression and initially just an `l` shows. I hit backspace and paste again then it fails with the full line. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation
---+
Reporter: pturnbull |Owner:
Type: bug | Status: new
Priority: normal |Milestone: 7.2.1
Component: GHCi| Version: 6.12.3
Keywords: MVar| Testcase:
Blockedby: | Difficulty:
Os: MacOS X | Blocking:
Architecture: x86_64 (amd64) | Failure: GHCi crash
---+
Comment(by Artyom.Kazak):
I'm using Windows 7, GHC 7.0.2. I don't know is it the same bug…
I was playing with my module called Helpers.Numeric located in file called
Numeric.hs. As you can see, I compiled it using GHC and by mistake ran
Numeric.hs instead of Numeric.exe, so I had GHCi in GHCi. Then I wanted to
enter ':q', but entered just 'q', and the inner GHCi crashed.
{{{
*Helpers.Numeric Math.Root.Finder> :! ghc --make -O2 -main-is
Halpers.Numeric Numeric.hs
[2 of 2] Compiling Helpers.Numeric ( Numeric.hs, Numeric.o )
*Helpers.Numeric Math.Root.Finder> :! Numeric.hs
GHCi, version 7.0.2: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Ok, modules loaded: Helpers.Numeric, Ratio'.
Prelude Helpers.Numeric>
Prelude Helpers.Numeric> q
:1:1: Not in scope: `q'
Prelude Helpers.Numeric>
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.0.2 for i386-unknown-mingw32):
thread blocked indefinitely in an MVar operation
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation ---+ Reporter: pturnbull |Owner: Type: bug | Status: new Priority: normal |Milestone: 7.2.1 Component: GHCi| Version: 6.12.3 Keywords: MVar| Testcase: Blockedby: | Difficulty: Os: MacOS X | Blocking: Architecture: x86_64 (amd64) | Failure: GHCi crash ---+ Changes (by altaic): * cc: william.knop.nospam@… (added) Comment: I confirmed that this bug exists on my recent x86_64 HEAD build targeting OS X 10.6. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation
---+
Reporter: pturnbull |Owner:
Type: bug | Status: new
Priority: normal |Milestone: 7.0.2
Component: GHCi| Version: 6.12.3
Keywords: MVar| Testcase:
Blockedby: | Difficulty:
Os: MacOS X | Blocking:
Architecture: x86_64 (amd64) | Failure: GHCi crash
---+
Changes (by paterno):
* version: 7.0.1 => 6.12.3
* os: Unknown/Multiple => MacOS X
* architecture: x86 => x86_64 (amd64)
Comment:
I can verify this problem appears in the Mac OS X release as well.
My output is below.
{{{
bash-$ uname -a
Darwin thomas 10.6.0 Darwin Kernel Version 10.6.0: Wed Nov 10 18:11:58 PST
2010; root:xnu-1504.9.26~3/RELEASE_X86_64 x86_64
bash-$ ghci
GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude>
[1]+ Stopped ghci
bash-$ fg
ghci
^C^C
Prelude>
ghc: panic! (the 'impossible' happened)
(GHC version 6.12.3 for i386-apple-darwin):
thread blocked indefinitely in an MVar operation
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation -+-- Reporter: pturnbull |Owner: Type: bug | Status: new Priority: normal|Milestone: 7.0.2 Component: GHCi | Version: 7.0.1 Keywords: MVar | Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: x86 | Failure: GHCi crash -+-- Comment(by simonmar): The Control-C behaviour on Windows was also reported as #4531. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation
-+--
Reporter: pturnbull |Owner:
Type: bug | Status: new
Priority: normal|Milestone: 7.0.2
Component: GHCi | Version: 7.0.1
Keywords: MVar | Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: x86 | Failure: GHCi crash
-+--
Comment(by Jafet):
Hi again. The previous message is incorrect; I didn't know that
{{{ghci.exe}}} always uses a child {{{ghc.exe}}} process.
What really happens on Windows is that {{{ghci.exe}}} is right away killed
by {{{^C}}}, and the child {{{ghc.exe}}} doesn't realize that until a
little later, so it goes into a panic. They also spawn some new threads
before they die for some reason. I've attached a trace by Process Monitor,
which records the syscalls made after {{{^C}}}.
Someone with a Mac could {{{ktrace}}} to check that it's really the same
bug.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation
-+--
Reporter: pturnbull |Owner:
Type: bug | Status: new
Priority: normal|Milestone: 7.0.2
Component: GHCi | Version: 7.0.1
Keywords: MVar | Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: x86 | Failure: GHCi crash
-+--
Changes (by Jafet):
* version: 6.12.3 => 7.0.1
* os: MacOS X => Unknown/Multiple
Comment:
I've encountered the same bug, but in the Windows console with GHC 7.0.1.
To reproduce:
1. Start {{{ghci}}} from cmd.exe (or Cygwin bash) in a console.
2. Press {{{^C}}}.
3. Hold down the return key.
{{{
C:\>ghci
GHCi, version 7.0.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> ^C
C:\>
Prelude>
C:\>
Prelude>
C:\>
... after a moment ...
Prelude>
C:\>
Prelude>
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.0.1 for i386-unknown-mingw32):
thread blocked indefinitely in an MVar operation
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
C:\>
C:\>
}}}
After {{{^C}}}, GHC backgrounds itself from cmd.exe and subsequent input
finds its way to the shell:
{{{
Prelude> ^C
C:\>
Prelude> input
'input' is not recognized as an internal or external command,
operable program or batch file.
C:\>input
'nput' is not recognized as an internal or external command,
operable program or batch file.
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation --+- Reporter: pturnbull |Owner: Type: bug| Status: new Priority: normal |Milestone: 6.14.1 Component: GHCi | Version: 6.12.3 Keywords: MVar | Testcase: Blockedby: | Difficulty: Os: MacOS X| Blocking: Architecture: x86| Failure: GHCi crash --+- Changes (by simonmar): * priority: high => normal Comment: Anyone with access to a Mac care to look into this one? It doesn't seem important enough to hold up the release for. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation --+- Reporter: pturnbull |Owner: Type: bug| Status: new Priority: high |Milestone: 6.14.1 Component: GHCi | Version: 6.12.3 Keywords: MVar | Testcase: Blockedby: | Difficulty: Os: MacOS X| Blocking: Architecture: x86| Failure: GHCi crash --+- Changes (by igloo): * priority: normal => high * milestone: => 6.14.1 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation
--+-
Reporter: pturnbull |Owner:
Type: bug| Status: new
Priority: normal |Milestone:
Component: GHCi | Version: 6.12.3
Keywords: MVar | Testcase:
Blockedby: | Difficulty:
Os: MacOS X| Blocking:
Architecture: x86| Failure: GHCi crash
--+-
Comment(by simonmar):
I don't see the bug on Linux, but I do see something else slightly
strange. After foregrounding GHCi again, the first Ctrl-C brings up
another `Prelude>` prompt which is fine, but if I then Ctrl-D to exit I
get
{{{
Prelude>
: hWaitForInput: end of file
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
#4245: ghci panic: thread blocked indefinitely in an MVar operation
--+-
Reporter: pturnbull | Owner:
Type: bug| Status: new
Priority: normal | Component: GHCi
Version: 6.12.3 |Keywords: MVar
Testcase: | Blockedby:
Os: MacOS X|Blocking:
Architecture: x86| Failure: GHCi crash
--+-
I stumbled across this error today:
{{{
phil ~
$ ghci
GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude>
[1]+ Stopped ghci
phil ~
$ fg
ghci
^C^C
Prelude>
ghc: panic! (the 'impossible' happened)
(GHC version 6.12.3 for i386-apple-darwin):
thread blocked indefinitely in an MVar operation
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
phil ~
$
}}}
Steps to reproduce:
* start ghci
* ctrl-z
* fg
* ctrl-c
* ctrl-c
* enter
* wait ~2 seconds
I'm not sure if it is related but while waiting for the impossible to
happen, any characters typed are not echoed to the screen.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4245>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3839: ghci panic reading pragmas (was: ghc panic reading pragmas)
#3839: ghci panic reading pragmas --+- Reporter: guest | Owner: Type: bug| Status: closed Priority: normal | Component: Compiler (Parser) Version: 6.10.4 | Resolution: fixed Keywords: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | --+- Changes (by guest): * status: new => closed * failure: None/Unknown => GHC rejects valid program * component: Compiler => Compiler (Parser) * resolution: => fixed Comment: I'm now told this is fixed in 6.12 so I guess it's ok to close. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3839#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2113: +++ ghci panic
#2113: +++ ghci panic -+-- Reporter: guest| Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi |Version: 6.6.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | -+-- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Fixed in 6.8.1+, see #1513 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2113#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2113: +++ ghci panic
#2113: +++ ghci panic
---+
Reporter: guest |Owner:
Type: bug | Status: new
Priority: normal |Milestone:
Component: GHCi| Version: 6.6.1
Severity: normal | Resolution:
Keywords: | Testcase:
Architecture: x86 | Os: MacOS X
---+
Comment (by guest):
Better formatting
{{{
Loading package base ... linking ... done.
Prelude> :module Control.Arrow
Prelude Control.Arrow> [1,2]+++[3,4]
ghc-6.6.1: panic! (the 'impossible' happened)
(GHC version 6.6.1 for i386-apple-darwin):
nameModule it{v aJ7}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2113#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #2113: +++ ghci panic
#2113: +++ ghci panic
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal | Component: GHCi
Version: 6.6.1 |Severity: normal
Keywords: |Testcase:
Architecture: x86 | Os: MacOS X
---+
Loading package base ... linking ... done.
Prelude> :module Control.Arrow
Prelude Control.Arrow> [1,2]+++[3,4]
ghc-6.6.1: panic! (the 'impossible' happened)
(GHC version 6.6.1 for i386-apple-darwin):
nameModule it{v aJ7}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2113>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-998514 ] GHCi panic bytecode vs object code -O2
Bugs item #998514, was opened at 2004-07-27 07:03 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=998514&group_id=8032 Category: Build System Group: 6.2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ben Lippmeier (lambintheloop) Assigned to: Nobody/Anonymous (nobody) Summary: GHCi panic bytecode vs object code -O2 Initial Comment: Compiling some source files with ghc -fglasgow-exts -O2 and some with GHCi results in GHCi panic. No FFI used in source. See attached tarball for source files and walkthrough. - ghc-6.2.1: panic! (the `impossible' happened, GHC version 6.2.1): Bytecode generator can't handle unboxed tuples. Possibly due to foreign import/export decls in source. Workaround: compile this module to a .o file, then restart session. Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. -- >Comment By: Simon Marlow (simonmar) Date: 2004-07-27 09:51 Message: Logged In: YES user_id=48280 Bug has been fixed, 6.2.2 will include the fix. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=998514&group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-998514 ] GHCi panic bytecode vs object code -O2
Bugs item #998514, was opened at 2004-07-27 17:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=998514&group_id=8032 Category: Build System Group: 6.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Ben Lippmeier (lambintheloop) Assigned to: Nobody/Anonymous (nobody) Summary: GHCi panic bytecode vs object code -O2 Initial Comment: Compiling some source files with ghc -fglasgow-exts -O2 and some with GHCi results in GHCi panic. No FFI used in source. See attached tarball for source files and walkthrough. - ghc-6.2.1: panic! (the `impossible' happened, GHC version 6.2.1): Bytecode generator can't handle unboxed tuples. Possibly due to foreign import/export decls in source. Workaround: compile this module to a .o file, then restart session. Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=998514&group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: ghci panic (unknown symbol stg_gc_l1)
Yes, Sigbjorn is of course right. Disregard my msg ... J | > Did you bootstrap using itself? | | no, that is the pb. Sigbjorn Finne gave the explaination: | | > > GHCi doesn't load the RTS package (nor GMP), | > > as they're both baked into the binary. My guess is that | > > you've built ghci using 5.02.1; you need to use 5.02.2 | > > (i.e., do two stage build.) The missing symbol was | > > introduced in 5.02.2's RTS. | | i bootstraped using itself, and now it works nicely :) | | > And finally, exactly what version of gcc do you have? | | an heavily patched 2.86 | ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci panic (unknown symbol stg_gc_l1)
"Julian Seward (Intl Vendor)" <[EMAIL PROTECTED]> writes: > > % ghci > > [...] > > Loading package std ... linking ... > > /usr/lib/ghc-5.02.2/HSstd.o: unknown symbol `stg_gc_l1' > > ghc-5.02.2: panic! (the `impossible' happened, GHC version 5.02.2): > > can't load package `std' > > [...] > > There's something very suspicious here, but it might be a > bug we know about. > > Did you build ghc yourself, from sources? yes > Did you bootstrap using itself? no, that is the pb. Sigbjorn Finne gave the explaination: > > GHCi doesn't load the RTS package (nor GMP), > > as they're both baked into the binary. My guess is that > > you've built ghci using 5.02.1; you need to use 5.02.2 > > (i.e., do two stage build.) The missing symbol was > > introduced in 5.02.2's RTS. i bootstraped using itself, and now it works nicely :) > And finally, exactly what version of gcc do you have? an heavily patched 2.86 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: ghci panic (unknown symbol stg_gc_l1)
There's something very suspicious here, but it might be a
bug we know about.
Did you build ghc yourself, from sources? Did you
bootstrap using itself? And finally, exactly what
version of gcc do you have?
J
| -Original Message-
| From: Pixel [mailto:[EMAIL PROTECTED]]
| Sent: Saturday, January 26, 2002 4:07 PM
| To: [EMAIL PROTECTED]
| Subject: ghci panic (unknown symbol stg_gc_l1)
|
|
| % ghci
| [...]
| Loading package std ... linking ...
| /usr/lib/ghc-5.02.2/HSstd.o: unknown symbol `stg_gc_l1'
| ghc-5.02.2: panic! (the `impossible' happened, GHC version 5.02.2):
| can't load package `std'
| [...]
|
|
| (it seems) it should load package "rts" before "std", but (it
| seems) it doesn't:
|
|
| % for i in /usr/lib/ghc-5.02.2/*.o; do nm $i | grep -q "T
| stg_gc_l1" && echo $i; done
| /usr/lib/ghc-5.02.2/HSrts.o
|
| % ghci -v5
| [...]
| Using package config file: /usr/lib/ghc-5.02.2/package.conf
| [...]
| Package
|{name = "std",
| import_dirs = ["/usr/lib/ghc-5.02.2/imports/std"],
| source_dirs = [],
| library_dirs = ["/usr/lib/ghc-5.02.2"],
| hs_libraries = ["HSstd"],
| extra_libraries = ["HSstd_cbits"],
| include_dirs = [],
| c_includes = ["HsStd.h"],
| package_deps = ["rts"],
| extra_ghc_opts = [],
| extra_cc_opts = [],
| [...]
| Loading package std ... linking ...
| /usr/lib/ghc-5.02.2/HSstd.o: unknown symbol `stg_gc_l1'
|
|
| "strace -efile ghci" doesn't show anything weird, except maybe:
| stat64("./Prelude.hs", 0xbfffcfe0) = -1 ENOENT (No such
| file or directory)
| stat64("./Prelude.lhs", 0xbfffcfe0) = -1 ENOENT (No such
| file or directory)
| stat64("./Prelude.hi-boot-5", 0xbfffcfe0) = -1 ENOENT (No
| such file or directory)
| stat64("./Prelude.hi-boot", 0xbfffcfe0) = -1 ENOENT (No such
| file or directory)
|
|
| I wanted to have a look at the code to find out what's wrong,
| but i can't find
| the time :-(
|
| ghci is built using
| http://people.mandrakesoft.com/| ~prigaux/ghc.spec where
|
| %configure is ./configure
| i586-mandrake-linux-gnu --prefix=/usr --exec-prefix=/usr
| --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
| --datadir=/usr/share --includedir=/usr/include
| --libdir=/usr/lib --libexecdir=/usr/lib
| --localstatedir=/var/lib --sharedstatedir=/usr/com
| --mandir=/usr/share/man --infodir=/usr/share/info
|
| Any idea what's wrong?
|
|
| Thanks
|
| --
| Pixel
| programming languages addict
| http://merd.net/pixel/language-study/
|
|
| ___
| Glasgow-haskell-bugs mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
|
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci panic (unknown symbol stg_gc_l1)
"Sigbjorn Finne" <[EMAIL PROTECTED]> writes: > GHCi doesn't load the RTS package (nor GMP), > as they're both baked into the binary. My guess is that > you've built ghci using 5.02.1; you need to use 5.02.2 > (i.e., do two stage build.) The missing symbol was > introduced in 5.02.2's RTS. cool, rebuilding :) thanks! PS: maybe some kind of warning could be added for this case? ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci panic (unknown symbol stg_gc_l1)
Hi,
GHCi doesn't load the RTS package (nor GMP),
as they're both baked into the binary. My guess is that
you've built ghci using 5.02.1; you need to use 5.02.2
(i.e., do two stage build.) The missing symbol was
introduced in 5.02.2's RTS.
hth
--sigbjorn
- Original Message -
From: "Pixel" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 26, 2002 08:07
Subject: ghci panic (unknown symbol stg_gc_l1)
> % ghci
> [...]
> Loading package std ... linking ... /usr/lib/ghc-5.02.2/HSstd.o: unknown
symbol `stg_gc_l1'
> ghc-5.02.2: panic! (the `impossible' happened, GHC version 5.02.2):
> can't load package `std'
> [...]
>
>
> (it seems) it should load package "rts" before "std", but (it seems) it
doesn't:
>
>
> % for i in /usr/lib/ghc-5.02.2/*.o; do nm $i | grep -q "T stg_gc_l1" &&
echo $i; done
> /usr/lib/ghc-5.02.2/HSrts.o
>
> % ghci -v5
> [...]
> Using package config file: /usr/lib/ghc-5.02.2/package.conf
> [...]
> Package
>{name = "std",
> import_dirs = ["/usr/lib/ghc-5.02.2/imports/std"],
> source_dirs = [],
> library_dirs = ["/usr/lib/ghc-5.02.2"],
> hs_libraries = ["HSstd"],
> extra_libraries = ["HSstd_cbits"],
> include_dirs = [],
> c_includes = ["HsStd.h"],
> package_deps = ["rts"],
> extra_ghc_opts = [],
> extra_cc_opts = [],
> [...]
> Loading package std ... linking ... /usr/lib/ghc-5.02.2/HSstd.o: unknown
symbol `stg_gc_l1'
>
>
> "strace -efile ghci" doesn't show anything weird, except maybe:
> stat64("./Prelude.hs", 0xbfffcfe0) = -1 ENOENT (No such file or
directory)
> stat64("./Prelude.lhs", 0xbfffcfe0) = -1 ENOENT (No such file or
directory)
> stat64("./Prelude.hi-boot-5", 0xbfffcfe0) = -1 ENOENT (No such file or
directory)
> stat64("./Prelude.hi-boot", 0xbfffcfe0) = -1 ENOENT (No such file or
directory)
>
>
> I wanted to have a look at the code to find out what's wrong, but i can't
find
> the time :-(
>
> ghci is built using http://people.mandrakesoft.com/~prigaux/ghc.spec where
> %configure is ./configure
i586-mandrake-linux-gnu --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin -
-sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/
include --libdir=/usr/lib --libexecdir=/usr/lib --localstatedir=/var/lib --s
haredstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info
>
> Any idea what's wrong?
>
>
> Thanks
>
> --
> Pixel
> programming languages addict http://merd.net/pixel/language-study/
>
> ___
> Glasgow-haskell-bugs mailing list
> [EMAIL PROTECTED]
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghci panic (unknown symbol stg_gc_l1)
% ghci
[...]
Loading package std ... linking ... /usr/lib/ghc-5.02.2/HSstd.o: unknown symbol
`stg_gc_l1'
ghc-5.02.2: panic! (the `impossible' happened, GHC version 5.02.2):
can't load package `std'
[...]
(it seems) it should load package "rts" before "std", but (it seems) it doesn't:
% for i in /usr/lib/ghc-5.02.2/*.o; do nm $i | grep -q "T stg_gc_l1" && echo $i; done
/usr/lib/ghc-5.02.2/HSrts.o
% ghci -v5
[...]
Using package config file: /usr/lib/ghc-5.02.2/package.conf
[...]
Package
{name = "std",
import_dirs = ["/usr/lib/ghc-5.02.2/imports/std"],
source_dirs = [],
library_dirs = ["/usr/lib/ghc-5.02.2"],
hs_libraries = ["HSstd"],
extra_libraries = ["HSstd_cbits"],
include_dirs = [],
c_includes = ["HsStd.h"],
package_deps = ["rts"],
extra_ghc_opts = [],
extra_cc_opts = [],
[...]
Loading package std ... linking ... /usr/lib/ghc-5.02.2/HSstd.o: unknown symbol
`stg_gc_l1'
"strace -efile ghci" doesn't show anything weird, except maybe:
stat64("./Prelude.hs", 0xbfffcfe0) = -1 ENOENT (No such file or directory)
stat64("./Prelude.lhs", 0xbfffcfe0) = -1 ENOENT (No such file or directory)
stat64("./Prelude.hi-boot-5", 0xbfffcfe0) = -1 ENOENT (No such file or directory)
stat64("./Prelude.hi-boot", 0xbfffcfe0) = -1 ENOENT (No such file or directory)
I wanted to have a look at the code to find out what's wrong, but i can't find
the time :-(
ghci is built using http://people.mandrakesoft.com/~prigaux/ghc.spec where
%configure is ./configure i586-mandrake-linux-gnu --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share
--includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/lib
--localstatedir=/var/lib --sharedstatedir=/usr/com --mandir=/usr/share/man
--infodir=/usr/share/info
Any idea what's wrong?
Thanks
--
Pixel
programming languages addict http://merd.net/pixel/language-study/
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci panic
Hi Sigbjorn, Thanks for the speedy reply! Sigbjorn Finne wrote: > "Antony Courtney" <[EMAIL PROTECTED]> writes: > > ... > >>Skipping HavenTest( HavenTest.hs, ./HavenTest.o ) >>PEi386 object has suspiciously large string table; > 64k relocs? >>ghc.exe: panic! (the `impossible' happened, GHC version 5.02.1): >> loadObj: failed >> >> > Hi, > > this is a known issue with GHCi's linker, for which there's no good > workaround for you other than to try to split up that module. > > If the module isn't particularly larger than any of the others, please > let us know. > Well the module on which it chokes (HavenTest) is not particularly large: $ wc -l HavenTest.hs 207 HavenTest.hs antony@AIRSTREAM /cygdrive/c/frp/haven/src/haskell $ ls -l HavenTest.o -rw-r--r--1 antony None93729 Jan 26 10:16 HavenTest.o but it has already loaded a particularly large module (HavenJavaBindings, which is 11k lines and a 3.3MB .o file). What's the limitation here? Can ghc or ghci be rebuilt to avoid this limit? Thanks, -antony -- Antony Courtney Grad. Student, Dept. of Computer Science, Yale University [EMAIL PROTECTED] http://www.apocalypse.org/pub/u/antony ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci panic
"Antony Courtney" <[EMAIL PROTECTED]> writes: > ... > Skipping HavenTest( HavenTest.hs, ./HavenTest.o ) > PEi386 object has suspiciously large string table; > 64k relocs? > ghc.exe: panic! (the `impossible' happened, GHC version 5.02.1): > loadObj: failed > Hi, this is a known issue with GHCi's linker, for which there's no good workaround for you other than to try to split up that module. If the module isn't particularly larger than any of the others, please let us know. --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghci panic
Hi, I got the following panic message when trying to load haven into ghci, and the panic message said that I should report the problem, so here you go. :) I am using ghc 5.02.1 under Windows 2000 / Cygwin. I'd really like to be able to use ghci for Haven development, so any ideas on what might be causing this would be most welcome. I'd be happy to make the exact setup available if you'd like to reproduce the bug yourselves. -antony $ ghci HavenTest ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.02.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package std ... linking ... done. Loading package lang ... linking ... done. Loading package concurrent ... linking ... done. Skipping StdDIS ( c:\greencard\gc-2.03\lib\ghc/StdDIS.hs, c:\greencar d\gc-2.03\lib\ghc/StdDIS.o ) Skipping GCJNI( c:\frp\gcjni\src/GCJNI.hs, c:\frp\gcjni\src/GCJNI.o ) Skipping JNI ( c:\frp\gcjni\src/JNI.hs, c:\frp\gcjni\src/JNI.o ) Skipping EnvM ( EnvM.hs, EnvM.o ) Skipping JNIBindings ( c:\frp\gcjni\src/JNIBindings.hs, c:\frp\gcjni\src/J NIBindings.o ) Skipping HavenJavaBindings ( HavenJavaBindings.hs, HavenJavaBindings.o ) Skipping HavenCoreJavaImpl ( HavenCoreJavaImpl.hs, HavenCoreJavaImpl.o ) Skipping HavenCore( HavenCore.hs, HavenCore.o ) Skipping HavenCoreUtils ( HavenCoreUtils.hs, HavenCoreUtils.o ) Skipping RenderM ( RenderM.hs, RenderM.o ) Skipping Haven( Haven.hs, Haven.o ) Skipping HavenTest( HavenTest.hs, ./HavenTest.o ) PEi386 object has suspiciously large string table; > 64k relocs? ghc.exe: panic! (the `impossible' happened, GHC version 5.02.1): loadObj: failed Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. Prelude> -- Antony Courtney Grad. Student, Dept. of Computer Science, Yale University [EMAIL PROTECTED] http://www.apocalypse.org/pub/u/antony ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghci panic on unloadObj
ghci -iutil:events -syslib lang -syslib data -syslibconcurrent util/object.o [ lots of stuff skipped ] Events> :load GuardedEvents unloadObj: can't find `events/Events.o' to unload ghc-5.00.2: panic! (the `impossible' happened, GHC version 5.00.2): unloadObj: failed Please report it as a compiler bug to [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. Events was previously loaded. Indeed ghci displayed the messages: Skipping Events ( events/Events.hs, events/Events.o ) Ok, modules loaded: Events, Toggle, Computation, Spawn, Object, Maybes, Debug. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
