Opened 5 years ago

Last modified 4 years ago

#3971 new bug

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 Revisions:

Description

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

/usr/local/packages/ghc-6.12.1.20100330/lib/ghc-6.12.1.20100330/package.conf.d
   Cabal-1.8.0.3
   QuickCheck-2.1.0.3
   array-0.3.0.0
   base-3.0.3.2
   base-4.2.0.1
   bin-package-db-0.0.0.0
   binary-0.5.0.2
   bytestring-0.9.1.6
   containers-0.3.0.0
   directory-1.0.1.1
   Segmentation fault

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

 ./Setup configure --prefix=/usr/local/packages/ghc-6.12.1.20100330 -p
Configuring zlib-0.5.2.0...
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.)

Wolfram

Attachments (2)

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

Download all attachments as: .zip

Change History (18)

comment:1 Changed 5 years ago by wkahl

I now installed ghc-6.12.1.20100330 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.

Wolfram

comment:2 Changed 5 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.

Wolfram

comment:3 Changed 5 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-0.3.1.1 from Hackage (that's the version used by ghc-6.12.1), and compiling and running the script at http://code.haskell.org/~judah/TermTest.hs . What is the output?

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

comment:4 Changed 5 years ago by wkahl

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

 ./Setup configure --prefix=/usr/local/packages/ghc-6.10.4 -p
Configuring terminfo-0.3.1.1...
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:

 ./TermTest
"rxvt"
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 5 years ago by wkahl

Output of infocmp in mrxvt.

Changed 5 years ago by wkahl

Output of 'stty -a' in mrxvt.

comment:5 Changed 5 years ago by wkahl

In xterm, TermTest segfaults just the same.

comment:6 Changed 5 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):

http://code.haskell.org/~judah/TerminfoTest2.hs

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

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

comment:7 Changed 5 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 5 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 http://www.haskell.org/haskellwiki/GHC/Using_the_FFI ; 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."
  where
    putc c = do
        print ("Outputting:",c,toEnum (fromEnum c)::Char)
        return c

comment:9 Changed 5 years ago by wkahl

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

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:

 ./CallBacker
got squareW
Segmentation fault

comment:10 Changed 5 years ago by igloo

  • Component changed from Package system to Compiler (FFI)
  • Milestone set to _|_

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

comment:11 Changed 5 years ago by simonmar

  • Summary changed from ghc-pkg list segfaults in ghc-6.12.1.20100330 to FFI callback segfaults on PPC

comment:12 Changed 5 years ago by Mikolaj

  • Cc mikolaj.konarski@… added
  • Type of failure changed from None/Unknown to Runtime crash
  • Version changed from 6.12.1 RC1 to 6.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 http://hackage.haskell.org/trac/gtk2hs/ticket/1192).

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 5 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-3.0.3.2 to avoid conflict with later version base-4.2.0.2
wired-in package ghc-prim mapped to ghc-prim-0.2.0.0-13014a61d1bede2dccfcb74a207c457e
wired-in package integer-gmp mapped to integer-gmp-0.2.0.1-88f5d2ed86bd848c39089474706fa2f9
wired-in package base mapped to base-4.2.0.2-19a4e0bca43a8b040f5fa06af2f7275d
wired-in package rts mapped to builtin_rts
wired-in package haskell98 mapped to haskell98-1.0.1.1-fe1d74491ea84387f77ab267ccd18114
wired-in package template-haskell mapped to template-haskell-2.4.0.1-baf591d5102d871c9b9ab3f76a1ef428
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:
Deleting: 
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-4.2.0.2 -L/usr/local/lib/ghc-6.12.3/integer-gmp-0.2.0.1 -L/usr/local/lib/ghc-6.12.3/ghc-prim-0.2.0.0 -L/usr/local/lib/ghc-6.12.3 -lHSrtsmain -lHSbase-4.2.0.2 -lHSinteger-gmp-0.2.0.1 -lgmp -lHSghc-prim-0.2.0.0 -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 5 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 5 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-1.0.1.1 -lHSdirectory-1.0.1.1 -lHSunix-2.4.0.2 -lrt -lutil -ldl -lHSold-time-1.0.0.5 -lHSold-locale-1.0.0.2 -lHSfilepath-1.1.0.4 -lHScontainers-0.3.0.0 -lHSarray-0.3.0.1 -lHSbase-4.2.0.2 -lHSinteger-gmp-0.2.0.1 -lgmp -lHSghc-prim-0.2.0.0 -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 4 years ago by erikd

  • Cc mle+hs@… added
Note: See TracTickets for help on using tickets.