Segfault on getInputLine and getInputChar

[syfran]

Haskeline gives a seg fault when getInputLine or getInputChar is called.

import System.Console.Haskeline
main = runInputT defaultSettings $ getInputLine "$$" >> outputStrLn "Hello World" :: IO ()

This just outputs "Segmentation Fault" when compiled and run (or just quits if run with runghc)

On the other hand,

import System.Console.Haskeline
main= runInputT defaultSettings $ outputStrLn "Hello World" :: IO ()

will output "Hello World" as expected.

System Info--

OS: Gentoo Linux

Arch: amd64

ghc version: 6.10.4

haskeline version: 0.6.2.2

If it helps heres the result of gdb where on the above example:

 gdb ./Tests 
GNU gdb (Gentoo 7.1 p1) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /home/syfran/haskelineTests/Tests...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/syfran/haskelineTests/Tests 
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x0000000000535362 in base_ForeignziCziString_zdwa_info ()
(gdb) where
#0  0x0000000000535362 in base_ForeignziCziString_zdwa_info ()
#1  0x0000000000000000 in ?? ()
(gdb) 

Let me know if you need anything else.

[judah]

Sorry for the delay in reply. That information was very helpful in narrowing things down. One more question: For the first program (using getInputLine) which you have listed in the description, what happens if you run it as follows (e.g. if you compiled it as Test.hs)?

cat | ./Test

If that actually works, then there's only a few possible causes of the segfault. I'll put together a short program which replicates Haskeline's initialization steps with better debugging information; that should allow us to find the problem.

[judah]

Actually, one more test occurred to me which would be very helpful. Can you please run:

export TERM=dumb
./Test

and see whether that segfaults? (That's the bash syntax; use setenv if you're using csh or similar.)

[syfran]

Both methods cause the program to work as expected (just out of curiousity, how does this change how the program functions?)

Not sure if it still helps still but the gdb disassemble of the segfault shows

=> 0x00000000006adea1 <+33>:    movsbq (%r14),%rax

with r14 containing 0

being the segfault line (after the function has been called ~21 times)

I could post the whole disassemble, if you need it.

Thanks a lot for helping out here, not being able to use ghci getting to be a pain.

[syfran]

After trying the methods you gave for the Test program I tried them both on ghci, which also works but without tab completion and all that good stuff. So going along a similar line I tried using xterm instead of my current Eterm. Everything works perfectly there (including tab completion). It also works fine if I run

TERM="xterm" ghci

In Eterm, without actually having to use xterm. The same solution also works for darcs.

[judah]

OK, great. Sounds like there's a problem with the Haskell terminfo bindings package (which I also maintain). From what you said, I was able to get a bus error on my machine from within my own (non-eterm) terminal by running TERM=Eterm ghci.

Can you confirm that in Eterm, by default TERM=Eterm (with that exact capitalization)? I'll look into fixing this.

[syfran]

$ echo $TERM
Eterm

[judah]

Thanks for all your assistance; this should be fixed now. The issue was a C function in the terminfo library which was returning NULL instead of (as I expected) an empty null-terminated string.

I uploaded a new version of the terminfo package to Hackage. I suggest that you run

cabal update
cabal install --reinstall terminfo ghci-haskeline

This will install a "ghci-haskeline" executable which is linked against the fixed terminfo package.

I'm closing this ticket, but please reopen it if you encounter any other problems.