Opened 7 years ago

Closed 17 months ago

#3971 closed bug (fixed)

FFI callback segfaults on PPC

Reported by: wkahl Owned by:
Priority: normal Milestone:
Component: Compiler (FFI) Version: 6.12.3
Keywords: Cc: mikolaj.konarski@…, mle+hs@…
Operating System: Linux Architecture: powerpc
Type of failure: Runtime crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


ghc-pkg has been segfaulting ever since I installed ghc- on my G5 PowerPC running gentoo 32-bit userland; current state:

   Segmentation fault

(Now, trying to install zlib, I also get:

 ./Setup configure --prefix=/usr/local/packages/ghc- -p
Configuring zlib-
Setup: failed to parse output of 'ghc-pkg dump'

although I can see nothing wrong with the output of 'ghc-pkg dump' — reported under Bug 559 in the Cabal trac.)


Attachments (2)

infocmp.output (2.2 KB) - added by wkahl 7 years ago.
Output of infocmp in mrxvt.
stty_a.output (590 bytes) - added by wkahl 7 years ago.
Output of 'stty -a' in mrxvt.

Download all attachments as: .zip

Change History (19)

comment:1 Changed 7 years ago by wkahl

I now installed ghc- on my x86 laptop, too, and see that the line after directory comes out in blue.

I therefore suspect that the crash is due to terminfo, which I have reason to believe is also the culprit for the GHCi failure on PowerPC.


comment:2 Changed 7 years ago by wkahl

If I look at ghc-pkg.cabal, I cannot see where the curses dependency comes from.

termios.h, used by package unix, seems to come from glibc.


comment:3 Changed 7 years ago by judahj

If there's a problem with terminfo, it might be with the terminfo package (which is used to build GHC but not installed by default). Two things which could help detect that:

1) What do you get when you run the commands infocmp and stty -a?

2) Try installing terminfo- from Hackage (that's the version used by ghc-6.12.1), and compiling and running the script at . What is the output?

Make sure to run those commands from within whatever terminal you're getting the above errors in.

comment:4 Changed 7 years ago by wkahl

Configuring terminfo- produced a warning I have never seen before:

 ./Setup configure --prefix=/usr/local/packages/ghc-6.10.4 -p
Configuring terminfo-
configure: WARNING: unrecognized options: --with-compiler
checking for gcc... gcc
checking for unistd.h... yes
checking ncurses.h usability... yes
checking ncurses.h presence... yes
checking for ncurses.h... yes
checking for setupterm in -lncursesw... yes
configure: creating ./config.status
config.status: creating terminfo.buildinfo
configure: WARNING: unrecognized options: --with-compiler

Running in mrxvt-0.5.3-r2 produces:

Setup succeeded.
("am",Just True)
("lines",Just 64)
("keyRight",Just "\ESC[C")
("cursorRight",Just "\ESC[C")
Segmentation fault

The segfault is in:

    runTermOutput t $ fromJust $ getCapability t keypadOn

Last time I looked at terminfo, I saw far too much unsafePerformIO for my taste around things like getCapability, where I had the impression that most callers were inside IO anyway. Just the name getCapability already suggests an IO type --- however I didn't get around to fully converting it.

The other outputs will be attached.

Changed 7 years ago by wkahl

Attachment: infocmp.output added

Output of infocmp in mrxvt.

Changed 7 years ago by wkahl

Attachment: stty_a.output added

Output of 'stty -a' in mrxvt.

comment:5 Changed 7 years ago by wkahl

In xterm, TermTest segfaults just the same.

comment:6 Changed 7 years ago by judahj

OK, from what you've said I suspect something with the FFI. I've prepared another test script that runs through all of the FFI interactions involved in that line you mentioned (without any unsafePerformIO):

Please let me know the output; you can compile it with

ghc --make TerminfoTest2.hs -ffi -XEmptyDataDecls -XDeriveDataTypeable -lncurses

comment:7 Changed 7 years ago by wkahl

In mrxvt:

("Setting up:","rxvt")
("testing capability:","smkx",[])
About to call tigetstr
("tiGetStr: pointer result",0x10400a15)
("tiGetStr result:","\ESC=")
About to call tparm
("tParm pointer result:",0x10400e98)
("tiParm result:","\ESC=")
Making the callback function
Callback created.
Segmentation fault

In xterm:

("Setting up:","xterm")
("testing capability:","smkx",[])
About to call tigetstr
("tiGetStr: pointer result",0x102d1a53)
("tiGetStr result:","\ESC[?1h\ESC=")
About to call tparm
("tParm pointer result:",0x102d2290)
("tiParm result:","\ESC[?1h\ESC=")
Making the callback function
Callback created.
Segmentation fault

In urxvt (rxvt-unicode):

("Setting up:","rxvt-unicode")
("testing capability:","smkx",[])
About to call tigetstr
("tiGetStr: pointer result",0x1081ca78)
("tiGetStr result:","\ESC=")
About to call tparm
("tParm pointer result:",0x1081d518)
("tiParm result:","\ESC=")
Making the callback function
Callback created.
Segmentation fault

In gnome-terminal:

("Setting up:","xterm")
("testing capability:","smkx",[])
About to call tigetstr
("tiGetStr: pointer result",0x107bfa53)
("tiGetStr result:","\ESC[?1h\ESC=")
About to call tparm
("tParm pointer result:",0x107c0290)
("tiParm result:","\ESC[?1h\ESC=")
Making the callback function
Callback created.
Segmentation fault

comment:8 Changed 7 years ago by judahj

Ok, the problem is happening with a FFI "wrapper" function. I suspect that this is an issue with GHC's PowerPC support, rather than with the terminfo package itself. There's another good example at ; can you verify whether it works?

For reference, this is the relevant code from the test script:

foreign import ccall "wrapper" mkCallback :: CharOutput -> IO (FunPtr CharOutput)
foreign import ccall tputs :: CString -> CInt -> FunPtr CharOutput -> IO ()
type CharOutput = CInt -> IO CInt
tPuts :: String -> IO ()
tPuts s = do
    withCString s $ \c_str -> do
    putStrLn "Making the callback function"
    putc_ptr <- mkCallback putc
    putStrLn "Callback created."
    tputs c_str 1 putc_ptr
    putStrLn "Called tputs."
    freeHaskellFunPtr putc_ptr
    putStrLn "Freed callback."
    putc c = do
        print ("Outputting:",c,toEnum (fromEnum c)::Char)
        return c

comment:9 Changed 7 years ago by wkahl

The CallBacker example segfaults, too, both with GHC-6.10.4 and GHC-

I then changed main slightly:

main :: IO ()
main = do
  squareW <- wrap square     -- make function pointer from the function
  putStrLn "got squareW"
  let x = 4
  y <- twice squareW x       -- use the foreign function with our callback
  print y                    -- see that it worked
  z <- twice squareW y
  print z
  freeHaskellFunPtr squareW  -- clean up after ourselves

Running this produces:

got squareW
Segmentation fault

comment:10 Changed 7 years ago by igloo

Component: Package systemCompiler (FFI)
Milestone: _|_

This sounds like a PPC-specific problem, so it would need someone interested in PPC support to look into it.

comment:11 Changed 7 years ago by simonmar

Summary: ghc-pkg list segfaults in ghc- callback segfaults on PPC

comment:12 Changed 7 years ago by Mikolaj

Cc: mikolaj.konarski@… added
Type of failure: None/UnknownRuntime crash
Version: 6.12.1 RC16.12.3

Reproduced on the just released 6.12.3 (so probably unrelated to #4038) and on Debian's ghc6_6.12.1-13. I'm getting exactly the same output as reported above for the modified CallBacker and I have a similar problem when using callbacks in gth2hs (see

I'm quite ignorant here, but it may not only be PPC specific, but also processor model specific, because the relevant GHC code is written in assembler and you can't compile via C (-fvia-C does not work on PPC Linux, as reported elsewhere) to delegate emission of legal assembler code to GCC. My processor type is 7447A and gdb suggests some of the instructions emitted for callbacks are invalid.

comment:13 Changed 7 years ago by Mikolaj

I've compiled 6.12.3 in uregistered mode and then compiled the modified CallBacker with "fvia-C -funregisterised -static". The results are the same: "got squareW" and then a segfault. Couldn't test more precisely, because now assertions fail in binaries compiled with -debug already with trivial code. Compilation is not possible with fvia-C and registered mode, so that's it.

I've noticed some assembler is compiled by gcc even in unregistered mode, so if there are illegal instructions in this assembler, they are still there. I naively hoped everything is written in pure C... Some parts of the compilation log follow:

Glasgow Haskell Compiler, Version 6.12.3, for Haskell 98, stage 2 booted by GHC version 6.12.1
Using binary package database: /usr/local/lib/ghc-6.12.3/package.conf.d/package.cache
hiding package base- to avoid conflict with later version base-
wired-in package ghc-prim mapped to ghc-prim-
wired-in package integer-gmp mapped to integer-gmp-
wired-in package base mapped to base-
wired-in package rts mapped to builtin_rts
wired-in package haskell98 mapped to haskell98-
wired-in package template-haskell mapped to template-haskell-
wired-in package dph-seq mapped to dph-seq-0.4.0-fb29786cf6c57b51c4925845642c3924
wired-in package dph-par mapped to dph-par-0.4.0-e3b525c83d71c4b538adf092065ac467
Hsc static flags: -funregisterised -static


*** Assembler:
/usr/bin/gcc -I. -c /tmp/ghc10472_0/ghc10472_2.s -o CallBacker.o
*** Deleting temp files:
Deleting: /tmp/ghc10472_0/ghc10472_2.s /tmp/ghc10472_0/ghc10472_1.s /tmp/ghc10472_0/ghc10472_0.hc /tmp/ghc10472_0/ghc10472_0.s
Upsweep completely successful.
*** Deleting temp files:
link: linkables are ...
LinkableM (Tue Jun 15 20:04:29 CEST 2010) main:Main
   [DotO CallBacker.o, DotO CallBacker_stub.o]
Linking CallBacker ...
*** Linker:
/usr/bin/gcc -v -o CallBacker CallBacker.o CallBacker_stub.o callerback.o -L/usr/local/lib/ghc-6.12.3/base- -L/usr/local/lib/ghc-6.12.3/integer-gmp- -L/usr/local/lib/ghc-6.12.3/ghc-prim- -L/usr/local/lib/ghc-6.12.3 -lHSrtsmain -lHSbase- -lHSinteger-gmp- -lgmp -lHSghc-prim- -lHSrts -lm -lrt -ldl -u ghczmprim_GHCziTypes_Izh_static_info -u ghczmprim_GHCziTypes_Czh_static_info -u ghczmprim_GHCziTypes_Fzh_static_info -u ghczmprim_GHCziTypes_Dzh_static_info -u base_GHCziPtr_Ptr_static_info -u base_GHCziWord_Wzh_static_info -u base_GHCziInt_I8zh_static_info -u base_GHCziInt_I16zh_static_info -u base_GHCziInt_I32zh_static_info -u base_GHCziInt_I64zh_static_info -u base_GHCziWord_W8zh_static_info -u base_GHCziWord_W16zh_static_info -u base_GHCziWord_W32zh_static_info -u base_GHCziWord_W64zh_static_info -u base_GHCziStable_StablePtr_static_info -u ghczmprim_GHCziTypes_Izh_con_info -u ghczmprim_GHCziTypes_Czh_con_info -u ghczmprim_GHCziTypes_Fzh_con_info -u ghczmprim_GHCziTypes_Dzh_con_info -u base_GHCziPtr_Ptr_con_info -u base_GHCziPtr_FunPtr_con_info -u base_GHCziStable_StablePtr_con_info -u ghczmprim_GHCziBool_False_closure -u ghczmprim_GHCziBool_True_closure -u base_GHCziPack_unpackCString_closure -u base_GHCziIOziException_stackOverflow_closure -u base_GHCziIOziException_heapOverflow_closure -u base_ControlziExceptionziBase_nonTermination_closure -u base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -u base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -u base_ControlziExceptionziBase_nestedAtomically_closure -u base_GHCziWeak_runFinalizzerBatch_closure -u base_GHCziTopHandler_runIO_closure -u base_GHCziTopHandler_runNonIO_closure -u base_GHCziConc_ensureIOManagerIsRunning_closure -u base_GHCziConc_runSparks_closure -u base_GHCziConc_runHandlers_closure -lHSffi
Using built-in specs.
Target: powerpc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --disable-softfloat --enable-secureplt --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --disable-werror --with-long-double-128 --enable-checking=release --build=powerpc-linux-gnu --host=powerpc-linux-gnu --target=powerpc-linux-gnu


comment:14 Changed 7 years ago by simonmar

If you get assertion failures, that's a good sign, because the assertion has spotted something wrong before the crash.

Someone with some PPC expertise will need to debug this using gdb. Volunteers? We're happy to help with debugging tips and helping find your way around the RTS. See also Debugging/CompiledCode.

comment:15 Changed 7 years ago by Mikolaj

About -debug assert failure, I was doubly wrong: it's a segfault (illegal memory access) while computing the assertion and it's caused by using a leftover rts_debug library in /usr/local, from an earlier registerized build of 6.12.3. It appears, there is no rts_debug in my unregisterized build, since after cleaning /usr/local and reinstalling I see when compiling with "-debug -v":

[...]-lHSpretty- -lHSdirectory- -lHSunix- -lrt -lutil -ldl -lHSold-time- -lHSold-locale- -lHSfilepath- -lHScontainers- -lHSarray- -lHSbase- -lHSinteger-gmp- -lgmp -lHSghc-prim- -lHSrts_debug -lm -lrt -ldl -lHSffi -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/powerpc-linux-gnu/4.4.3/crtend.o /usr/lib/gcc/powerpc-linux-gnu/4.4.3/../../../../lib/crtn.o
/usr/bin/ld: cannot find -lHSrts_debug

comment:16 Changed 6 years ago by erikd

Cc: mle+hs@… added

comment:17 Changed 17 months ago by erikd

Resolution: fixed
Status: newclosed

Just compiled and ran the `CallBacker" example on PowerPC with ghc 7.8.4 (last stable release) and ghc 7.10.2 (the current stable release).

Both worked fine without any segfault.

Closing this as fixed.

Note: See TracTickets for help on using tickets.