Ticket #133 (new defect)

Opened 4 months ago

Last modified 4 months ago

haskeline segfaults when used in ghci

Reported by: mvanier Owned by: judah
Priority: major Milestone:
Version: Keywords:
Cc:

Description

The attached file, when run in ghci, segfaults as soon as the first input is received. A sample interaction:

*Main> main

sdfasdf... [entering characters]

and a segfault occurs. This is a very weird bug. It doesn't happen if the file is compiled and run, and it doesn't happen if characters are entered very slowly. But entering about seven rapidly-typed characters reliably triggers a segfault.

This is using GHC 7.8.2 on Mac OS X Mavericks.

Attachments

Main.hs (291 bytes) - added by mvanier 4 months ago.
Trivial read-eval-print loop which triggers a segfault when run in ghci.

Change History

Changed 4 months ago by mvanier

Trivial read-eval-print loop which triggers a segfault when run in ghci.

Changed 4 months ago by mvanier

Actually, I found an even simpler example:

Prelude> import System.Console.Haskeline Prelude System.Console.Haskeline> runInputT defaultSettings (getInputLine "> ") Loading package filepath-1.3.0.2 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package unix-2.7.0.1 ... linking ... done. Loading package directory-1.2.1.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package terminfo-0.4.0.0 ... linking ... done. Loading package transformers-0.4.1.0 ... linking ... done. Loading package haskeline-0.7.1.3 ... linking ... done.

asdfsdsa [followed by segfault]

Also, I now see that entering characters slowly doesn't prevent it from segfaulting. This is (as you can see) with haskeline-0.7.1.3. All libraries have been installed via cabal.

Changed 4 months ago by mvanier

The formatting above is screwed up. This is better:

Prelude> import System.Console.Haskeline
Prelude System.Console.Haskeline> runInputT defaultSettings (getInputLine "> ")
Loading package filepath-1.3.0.2 ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package old-locale-1.0.0.6 ... linking ... done.
Loading package time-1.4.2 ... linking ... done.
Loading package bytestring-0.10.4.0 ... linking ... done.
Loading package unix-2.7.0.1 ... linking ... done.
Loading package directory-1.2.1.0 ... linking ... done.
Loading package containers-0.5.5.1 ... linking ... done.
Loading package terminfo-0.4.0.0 ... linking ... done.
Loading package transformers-0.4.1.0 ... linking ... done.
Loading package haskeline-0.7.1.3 ... linking ... done.
> fssdfasfdsadfa [followed by segfault]

Changed 4 months ago by judah

  • owner set to judah

Thanks for the report; this is very strange behavior. Unfortunately I don't have Mavericks so I'm not sure how much I'll be able to debug this currently.

GHCi itself uses Haskeline, so it's possible the bug is triggered by nested InputT environments. But I just tried on OS X Lion with ghc-7.6.1 and wasn't able to reproduce the error.

Does this also happen with Mavericks on earlier versions of GHC (say, 7.6.*)?

Another long shot: if you make the terminal window twice as wide, does it change how many characters you need to enter to trigger the segfault?

Note: See TracTickets for help on using tickets.