sh4: ghc randomly segfaults on qemu-sh4-static
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| QEMU |
Expired
|
Undecided
|
Unassigned | ||
Bug Description
Hello!
I am currently in the process of bootstrapping ghc for the Debian sh4 port and ran into a strange problem with qemu-sh4-static which randomly segfaults when running ghc to compile a Haskell source:
root@jessie32:
Main.hi Main.hs Setup.hs ghc-pwd.cabal ghc.mk
root@jessie32:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
root@jessie32:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
root@jessie32:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
root@jessie32:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
root@jessie32:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
[1 of 1] Compiling Main ( Main.hs, Main.o )
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
root@jessie32:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
[1 of 1] Compiling Main ( Main.hs, Main.o )
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
root@jessie32:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
[1 of 1] Compiling Main ( Main.hs, Main.o )
Bad interface file: /usr/local/
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.3 for sh4-unknown-linux):
getSymtabName:
<<details unavailable>>
Please report this as a GHC bug: http://
root@jessie32:
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
[1 of 1] Compiling Main ( Main.hs, Main.o )
Linking Main ...
root@jessie32:
As seen above, compiling a Haskell source code often results in a segfault but simply by retrying to run ghc over and over again, the compile process will eventually succeed and no segfault occurs.
I have created a tarball which contains the sh4 chroot from the example above which also includes ghc, gcc and the source code in question (in /root/ghc-
> http://
In case anyone wants to try ghc with their own sh4 chroot, here's my version of ghc:
> https:/
Just extract this tarball into the root directory of the sh4 chroot.
Please note, that it might be advisable on sh4 to apply the patches from these two bug reports as otherwise qemu-sh4-static won't work properly on amd64 and misses syscall 186:
> https:/
> https:/
The above issue is reproducible with the two patches applied and without. It's also reproducible with both libc6 2.19 and 2.21 in the chroot. Thus, I am currently out of ideas what else to test.
Cheers,
Adrian
| description: | updated |

Thank you for the 611 MB tar....
The behavior is a little bit different on my system:
root@Quad:~# ls 4-9~bpo8+ 1.dsc 4-9~bpo8+ 1.debian. tar.xz ghc_7.8. 4.orig. tar.xz 4/utils/ ghc-p 4/utils/ ghc-p 4/utils/ ghc-pwd/ ~/ghc-7. 8.4/utils/ ghc-pwd# ls ~/ghc-7. 8.4/utils/ ghc-pwd# ghc Main ~/ghc-7. 8.4/utils/ ghc-pwd# ghc Main.hs ~/ghc-7. 8.4/utils/ ghc-pwd# ghc Main.hs ~/ghc-7. 8.4/utils/ ghc-pwd# ghc Main.hs ~/ghc-7. 8.4/utils/ ghc-pwd# ghc Main.hs ~/ghc-7. 8.4/utils/ ghc-pwd# ghc Main.hs ~/ghc-7. 8.4/utils/ ghc-pwd# ghc Main.hs mutex_lock. c:80: __pthread_ mutex_lock: Assertion `mutex- >__data. __owner == 0' failed.
ghc-7.8.4 ghc_7.8.
ghc_7.8.
root@Quad:~# cd ghc-7.8.
ghc-pkg/ ghc-pwd/
root@Quad:~# cd ghc-7.8.
ghc-pkg/ ghc-pwd/
root@Quad:~# cd ghc-7.8.
root@Quad:
Main Main.hi Main.hs Main.o Setup.hs ghc-pwd.cabal ghc.mk
root@Quad:
Main Main.hi Main.hs Main.o
root@Quad:
root@Quad:
root@Quad:
root@Quad:
root@Quad:
root@Quad:
ghc: pthread_
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted (core dumped)
The emulated "tas.b" instruction is not atomic, this is why sometimes the locking fails...