Re: Segmentation fault/access violation in generated code
On 23 June 2012 02:40, Ian Lynagh ig...@earth.li wrote:
Hi Bas,
On Sun, Jun 17, 2012 at 05:11:35PM +0200, Bas van Dijk wrote:
module Main where
import Foreign
import qualified Foreign.Concurrent as FC
import Control.Concurrent
import Bindings.Libusb.InitializationDeinitialization
main :: IO ()
main = do
ctxPtr - alloca $ \ctxPtrPtr - do
_ - c'libusb_init ctxPtrPtr
peek ctxPtrPtr
fp - newForeignPtr p'libusb_exit ctxPtr
-- fp - FC.newForeignPtr ctxPtr $ c'libusb_exit ctxPtr
threadDelay 300
print $ fp == fp
What happens if you just call
c'libusb_exit ctxPtr
at the end, instead of using a finalizer?
Then I don't get an error. So executing the following program with the
argument fp gives an error (although this time I don't get an access
violation but instead Windows pops up a dialog box indicating an
error) and without an argument I get no error:
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
import Foreign
import Foreign.C.Types
import Control.Concurrent
import System.Environment
main :: IO ()
main = do
ctxPtr - alloca $ \ctxPtrPtr - do
_ - c'libusb_init ctxPtrPtr
peek ctxPtrPtr
args - getArgs
case args of
[fp] - do
fp - newForeignPtr p'libusb_exit ctxPtr
threadDelay 100
print $ fp == fp
_ - c'libusb_exit ctxPtr
data C'libusb_context = C'libusb_context
foreign import stdcall libusb_init c'libusb_init
:: Ptr (Ptr C'libusb_context) - IO CInt
foreign import stdcall libusb_exit p'libusb_exit
:: FunPtr (Ptr C'libusb_context - IO ())
foreign import stdcall libusb_exit c'libusb_exit
:: Ptr C'libusb_context - IO ()
Are you able to reproduce this with just a .c file that is compiled and
linked with the program, rather than needing libusb? That would make it
easier to reproduce, to understand, and to add a test.
I'm not sure how to do this. I guess just copying the libusb .c and .h
files to the same directory as the .hs file is not enough since libusb
requires a configure phase.
Regards,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Segmentation fault/access violation in generated code
Hi Bas, On Sun, Jun 17, 2012 at 05:11:35PM +0200, Bas van Dijk wrote: module Main where import Foreign import qualified Foreign.Concurrent as FC import Control.Concurrent import Bindings.Libusb.InitializationDeinitialization main :: IO () main = do ctxPtr - alloca $ \ctxPtrPtr - do _ - c'libusb_init ctxPtrPtr peek ctxPtrPtr fp - newForeignPtr p'libusb_exit ctxPtr -- fp - FC.newForeignPtr ctxPtr $ c'libusb_exit ctxPtr threadDelay 300 print $ fp == fp What happens if you just call c'libusb_exit ctxPtr at the end, instead of using a finalizer? Are you able to reproduce this with just a .c file that is compiled and linked with the program, rather than needing libusb? That would make it easier to reproduce, to understand, and to add a test. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Segmentation fault/access violation in generated code
I just tried building the following program with the new GHC
win64_alpha1 and apart from warnings from using the unsupported
stdcall calling convention running the program doesn't give a
segmentation fault as it does when building the program with
GHC-7.4.2:
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
import Foreign
import Foreign.C.Types
main :: IO ()
main = do
ctxPtr - alloca $ \ctxPtrPtr - do
_ - c'libusb_init ctxPtrPtr
peek ctxPtrPtr
fp - newForeignPtr p'libusb_exit ctxPtr
threadDelay 100
print $ fp == fp
data C'libusb_context = C'libusb_context
foreign import stdcall libusb_init c'libusb_init
:: Ptr (Ptr C'libusb_context) - IO CInt
foreign import stdcall libusb_exit p'libusb_exit
:: FunPtr (Ptr C'libusb_context - IO ())
Regards,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Segmentation fault in non-dynamically linked binaries?
This issue began manifesting in a lot of ways on my computer, not just GHC (but with ocaml, etc..) I did an upgrade of all my libc6-* related libraries, and the issue seems to have gone away (i.e. static linking works perfectly fine.) Sorry for the trouble On Wed, Jun 16, 2010 at 11:22 AM, austin seipp a...@0xff.ath.cx wrote: Forwarding this to g-h-u for archival purposes and in case anybody else has ideas (should'a done this earlier.) -- Forwarded message -- From: austin seipp a...@0xff.ath.cx Date: Wed, Jun 16, 2010 at 11:21 AM Subject: Re: Segmentation fault in non-dynamically linked binaries? To: Simon Marlow marlo...@gmail.com Follow up: Both of my machines are running debian x86_64 linux, both with libc6 version 2.11.2-1 (aka eglibc,) from debian sid. My work machine does not exhibit the same segfaulting behavior as my home machine. Debugging with the rts source available and watching setFullProgArgv go by does not help a lot - when stgCallocBytes is called with strlen as a parameter (to determine how much to allocate,) the code immediately crashes upon arrival into the first instruction of strlen, but the strange thing is *which* strlen it is jumping to. From a simple 'hello world' executable on my work machine, when disassembling setFullProgArgv we get this: ... 0x00432a26 setFullProgArgv+54: xor %ebp,%ebp 0x00432a28 setFullProgArgv+56: nopl 0x0(%rax,%rax,1) 0x00432a30 setFullProgArgv+64: mov (%r14,%rbp,1),%rdi 0x00432a34 setFullProgArgv+68: mov %rbp,%rbx 0x00432a37 setFullProgArgv+71: add 0x247f5a(%rip),%rbx # 0x67a998 full_prog_argv 0x00432a3e setFullProgArgv+78: add $0x1,%r12d 0x00432a42 setFullProgArgv+82: callq 0x4028b8 str...@plt 0x00432a47 setFullProgArgv+87: lea 0x1(%rax),%edi 0x00432a4a setFullProgArgv+90: mov $0x4616fe,%esi 0x00432a4f setFullProgArgv+95: callq 0x434790 stgMallocBytes 0x00432a54 setFullProgArgv+100: mov %rax,(%rbx) 0x00432a57 setFullProgArgv+103: mov 0x247f3a(%rip),%rax ... Note that it calls str...@plt which jumps to libc's implementation of strlen. However, when looking at this same program compiled on my home machine, we instead get: ... 0x00432db6 +54: xor %ebp,%ebp 0x00432db8 +56: nopl 0x0(%rax,%rax,1) 0x00432dc0 +64: mov (%r14,%rbp,1),%rdi 0x00432dc4 +68: mov %rbp,%rbx 0x00432dc7 +71: add 0x24898a(%rip),%rbx # 0x67b758 full_prog_argv 0x00432dce +78: add $0x1,%r12d 0x00432dd2 +82: callq 0x67b3c0 strlen@@GLIBC_2.2.5 0x00432dd7 +87: lea 0x1(%rax),%edi 0x00432dda +90: mov $0x46207e,%esi 0x00432ddf +95: callq 0x434cb0 stgMallocBytes 0x00432de4 +100: mov %rax,(%rbx) 0x00432de7 +103: mov 0x24896a(%rip),%rax # 0x67b758 full_prog_argv ... Here we call a version of strlen which the dynamic linker enforces come from glibc v2.2.5. If we run objdump -x, we get: ... Version References: required from librt.so.1: 0x09691973 0x00 04 GLIBC_2.3.3 required from libm.so.6: 0x09691a75 0x00 03 GLIBC_2.2.5 required from libc.so.6: 0x0d696913 0x00 05 GLIBC_2.3 0x09691a75 0x00 02 GLIBC_2.2.5 ... So there are some dependencies on older GLIBC versions for certain symbols, but I'm not sure why. I'm at work agaom so I'll follow up again here in a few hours once I get back home after doing some more reading. On Tue, Jun 15, 2010 at 3:43 PM, austin seipp a...@0xff.ath.cx wrote: Simon, Thanks for the reply. One interesting thing to note is that on my work machine, also running x86_64 debian, with with a full update from apt (many updates come from sid, others are from lenny,) static and dynamic linking both seem to work fine for the same versions of GHC that affect my home machine. On my debian machine here at work I have a libc6 which is installed from the unstable sid repository. It is libc6 version '2.11-1', which is actually a version of eglibc, not glibc (although eglibc is designed for full ABI-level compatibility - debian switched to it a while ago.) I believe my home machine with x86_64 debian has the exact same version of libc6 installed out of sid repos but I cannot confirm that at the moment. I do not currently have access to my home machine from here. When I do I'll get a copy of the 6.12.1 source code and do a debug link and do some more investigation. Thanks, On Tue, Jun 15, 2010 at 5:33 AM, Simon Marlow marlo...@gmail.com wrote: On 13/06/2010 07:26, austin seipp wrote: Hello, I am running GHC on x86_64 debian linux, and recently I have discovered that the executables generated by my GHC segfault when the linking step
Re: Segmentation fault in non-dynamically linked binaries?
On 13/06/2010 07:26, austin seipp wrote: Hello, I am running GHC on x86_64 debian linux, and recently I have discovered that the executables generated by my GHC segfault when the linking step is not dynamic. I discovered this while attempting to install haskell-src-exts, which requires a linked version of Setup.hs when cabal builds it (and which would fail inexplicably until I did further investigation.) Example: link ~/t » cat hi.hs main :: IO () main = putStrLn hi link ~/t » ghc -dynamic hi.hs link ~/t » file ./a.out ./a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped link ~/t » ldd ./a.out linux-vdso.so.1 = (0x7fffbadff000) libHShaskell98-1.0.1.1-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/haskell98-1.0.1.1/libHShaskell98-1.0.1.1-ghc6.12.3.so (0x7fab3a4c4000) libHSrandom-1.0.0.2-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/random-1.0.0.2/libHSrandom-1.0.0.2-ghc6.12.3.so (0x7fab3a2af000) libHStime-1.1.4-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/time-1.1.4/libHStime-1.1.4-ghc6.12.3.so (0x7fab39fad000) libHSprocess-1.0.1.3-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/process-1.0.1.3/libHSprocess-1.0.1.3-ghc6.12.3.so (0x7fab39d93000) libHSdirectory-1.0.1.1-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/directory-1.0.1.1/libHSdirectory-1.0.1.1-ghc6.12.3.so (0x7fab39b77000) libHSunix-2.4.0.2-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/unix-2.4.0.2/libHSunix-2.4.0.2-ghc6.12.3.so (0x7fab398c6000) librt.so.1 = /lib/librt.so.1 (0x7fab396a2000) libutil.so.1 = /lib/libutil.so.1 (0x7fab3949f000) libdl.so.2 = /lib/libdl.so.2 (0x7fab3929b000) libHSold-time-1.0.0.5-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/old-time-1.0.0.5/libHSold-time-1.0.0.5-ghc6.12.3.so (0x7fab3903c000) libHSold-locale-1.0.0.2-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/old-locale-1.0.0.2/libHSold-locale-1.0.0.2-ghc6.12.3.so (0x7fab38e28000) libHSfilepath-1.1.0.4-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/filepath-1.1.0.4/libHSfilepath-1.1.0.4-ghc6.12.3.so (0x7fab38c07000) libHSarray-0.3.0.1-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/array-0.3.0.1/libHSarray-0.3.0.1-ghc6.12.3.so (0x7fab38992000) libHSbase-4.2.0.2-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/base-4.2.0.2/libHSbase-4.2.0.2-ghc6.12.3.so (0x7fab381f2000) libHSinteger-gmp-0.2.0.1-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/integer-gmp-0.2.0.1/libHSinteger-gmp-0.2.0.1-ghc6.12.3.so (0x7fab37fe1000) libgmp.so.3 = /usr/lib/libgmp.so.3 (0x7fab37da1000) libHSghc-prim-0.2.0.0-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/ghc-prim-0.2.0.0/libHSghc-prim-0.2.0.0-ghc6.12.3.so (0x7fab37b1c000) libHSrts-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/libHSrts-ghc6.12.3.so (0x7fab378ba000) libm.so.6 = /lib/libm.so.6 (0x7fab37637000) libHSffi-ghc6.12.3.so = /usr/local/lib/ghc-6.12.3/libHSffi-ghc6.12.3.so (0x7fab3742a000) libc.so.6 = /lib/libc.so.6 (0x7fab370c9000) libpthread.so.0 = /lib/libpthread.so.0 (0x7fab36eac000) /lib64/ld-linux-x86-64.so.2 (0x7fab3a6cb000) link ~/t » ./a.out hi link ~/t » rm ./a.out *.hi *.o link ~/t » ghc hi.hs link ~/t » file ./a.out ./a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped link ~/t » ldd ./a.out linux-vdso.so.1 = (0x7fffaafff000) librt.so.1 = /lib/librt.so.1 (0x7fdf83d77000) libutil.so.1 = /lib/libutil.so.1 (0x7fdf83b74000) libdl.so.2 = /lib/libdl.so.2 (0x7fdf8396f000) libgmp.so.3 = /usr/lib/libgmp.so.3 (0x7fdf8373) libm.so.6 = /lib/libm.so.6 (0x7fdf834ae000) libc.so.6 = /lib/libc.so.6 (0x7fdf8314c000) libpthread.so.0 = /lib/libpthread.so.0 (0x7fdf82f3) /lib64/ld-linux-x86-64.so.2 (0x7fdf83f9c000) link ~/t » ./a.out [1]7850 segmentation fault ./a.out link ~/t » gdb7.0 ./a.out 139 ↵ GNU gdb (GDB) 7.0 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or laterhttp://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-unknown-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/a/t/a.out...done. (gdb) r Starting program: /home/a/t/a.out [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. 0x0067b3c0 in strlen@@GLIBC_2.2.5 () (gdb) bt #0 0x0067b3c0 in strlen@@GLIBC_2.2.5 () #1 0x00432dd7 in setFullProgArgv () #2
Re: segmentation fault in Gtk2Hs callbacks
On 06/05/2010 09:15, Axel Simon wrote: Good morning, I'm looking at ticket http://hackage.haskell.org/trac/ghc/ticket/4038 and wonder who is to blame: - this segmentation fault occurs in Gtk2Hs' callbacks (i.e. a Haskell function pointer is being passed to C land) and in a signal (where a general machinery is used to invoke a Haskell function), thus, it doesn't seem to be the way callbacks are used - the segfault only occurs in ghc 6.12.2 not in ghc 6.12.1 However, in the release notes of 6.12.2 there are no changes indicated that look like the RTS has changed. So I would like to simply ask: Are any of the GHC developers aware of any change in the concurrency or GC behaviour in GHC's RTS? Have any other parameters changed (perhaps something with multithreading?). Neither Gtk2Hs nor GHC seem to have changed, yet, there are these intermittend segfaults. It would be good to know which part is the culprit. It's my fault, I'm afraid. To fix a deadlock bug in 6.12.1, we merged a patch that changed some of the RTS data structures used for callbacks, and unfortunately that patch had a bug affecting nested callbacks. We didn't have a test for that case, so we didn't notice the bug. I'm working on getting the fix in right now, and we'll push out 6.12.3 with the fix as soon as we can. Sorry about this. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Segmentation fault trying to build ghc 6.10.1 using macports, Mac OS X 10.5, PPC
On Mon, Feb 2, 2009 at 9:58 AM, Gregory Wright gwri...@comcast.net wrote: On Feb 2, 2009, at 4:48 AM, Christian Maeder wrote: David Menendez wrote: I'm trying to upgrade GHC to 6.10.1 using macports on a PowerBook G4 running OS X 10.5.5. From what I can tell, I'm getting a segmentation fault from cabal-bin. On PPC leopard you need to update to XCode 3.1 http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX http://hackage.haskell.org/trac/ghc/ticket/2887 HTH Christian It would be very helpful to know if this solves the problem for you. I've had reports of similar failures on 10.4, but have not been able to reproduce them on a ppc/10.4 machine or a ppc/10.5 machine. Even with Xcode 3.0, it seems as if not everyone gets tagged by the error. This took care of the problem for me. Thanks. -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Segmentation fault trying to build ghc 6.10.1 using macports, Mac OS X 10.5, PPC
Hi David, On Feb 2, 2009, at 4:48 AM, Christian Maeder wrote: David Menendez wrote: I'm trying to upgrade GHC to 6.10.1 using macports on a PowerBook G4 running OS X 10.5.5. From what I can tell, I'm getting a segmentation fault from cabal-bin. On PPC leopard you need to update to XCode 3.1 http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX http://hackage.haskell.org/trac/ghc/ticket/2887 HTH Christian It would be very helpful to know if this solves the problem for you. I've had reports of similar failures on 10.4, but have not been able to reproduce them on a ppc/10.4 machine or a ppc/10.5 machine. Even with Xcode 3.0, it seems as if not everyone gets tagged by the error. Greg This is possibly related to http://trac.macports.org/ticket/15142 and http://hackage.haskell.org/trac/ghc/ticket/2380. cd extensible-exceptions /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ cabal-bin /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ bootstrapping.conf configure --distpref=dist-bootstrapping --with-compiler=/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc --with-hc-pkg=/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc-pkg --package-db=/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ bootstrapping.conf.tmp /bin/sh: line 1: 19203 Segmentation fault /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ cabal-bin /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ bootstrapping.conf configure --distpref=dist-bootstrapping --with-compiler=/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc --with-hc-pkg=/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc-pkg --package-db=/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/ bootstrapping.conf.tmp make[1]: *** [bootstrapping.conf] Error 139 make: *** [stage1] Error 2 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Segmentation fault trying to build ghc 6.10.1 using macports, Mac OS X 10.5, PPC
David Menendez wrote: I'm trying to upgrade GHC to 6.10.1 using macports on a PowerBook G4 running OS X 10.5.5. From what I can tell, I'm getting a segmentation fault from cabal-bin. On PPC leopard you need to update to XCode 3.1 http://hackage.haskell.org/trac/ghc/wiki/Building/MacOSX http://hackage.haskell.org/trac/ghc/ticket/2887 HTH Christian This is possibly related to http://trac.macports.org/ticket/15142 and http://hackage.haskell.org/trac/ghc/ticket/2380. cd extensible-exceptions /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/cabal-bin /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf configure --distpref=dist-bootstrapping --with-compiler=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc --with-hc-pkg=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc-pkg --package-db=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf.tmp /bin/sh: line 1: 19203 Segmentation fault /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/cabal-bin /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf configure --distpref=dist-bootstrapping --with-compiler=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc --with-hc-pkg=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-bootstrap/bin/ghc-pkg --package-db=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/libraries/bootstrapping.conf.tmp make[1]: *** [bootstrapping.conf] Error 139 make: *** [stage1] Error 2 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Segmentation Fault
I've now done a 3-stage bootstrap using exactly the same versions of GHC 4.04, gcc 2.95.2 and Solaris 7. Everything worked without a hitch. OK, after hacking ghc-inplace to stop it deleting all its files (is there a --keep-everything option?) and running hsc inside gdb I get: Glasgow Haskell Compiler, version 4.06, for Haskell 98, compiled by GHC version 4.06 Program received signal SIGSEGV, Segmentation fault. 0x90062010 in ?? () (gdb) bt #0 0x90062010 in ?? () #1 0xa7db74 in schedule () #2 0xa7e080 in waitThread () #3 0xa7c8a8 in rts_evalIO () #4 0xa7c2b8 in main () I'll keep the gdb session alive for the rest of today if you have any more queries. You could try building your RTS with debugging options (look in fptools/mk/config.mk for the details). This is the RTS on the stage 1 compiler. Then relink the stage 2 compiler, and run gdb again. You should get more informative debugging info. We'll hold off on 4.06 until we've got a better handle on this one. Cheers, Simon
Re: Segmentation Fault
Simon Marlow wrote: Our nightly build did a two-stage bootstrap last night on a Sparc/Solaris system successfully ~/builds uname -a SunOS gigha 5.7 Generic_106541-04 sun4u sparc SUNW,Ultra-5_10 uname -a SunOS titania 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-1 ~/builds gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) gcc -v Reading specs from /usr/local/lang/gnu/lib/gcc-lib/sparcv9-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) Stage 1 was build with 4.04pl1 (make sure you have pl1!), and stage 2 was cksum ghc-4.04-sparc-sun-solaris2.tar.gz 2269644928 6114825 ghc-4.04-sparc-sun-solaris2.tar.gz bootstrapped. I've just done a stage 3 build too, which went through without a hitch. Was the stage 2 build installed in a separate directory as it was here, or eas it in place? So I'm at a loss now: Marc reported that downgrading his gcc fixed the problem. That suggests that it's a gcc bug, but we're using 2.95.2 here without any difficulties. There's also the outstanding build problem related to sigset_t, which I also can't reproduce. Any insight appreciated. OK, after hacking ghc-inplace to stop it deleting all its files (is there a --keep-everything option?) and running hsc inside gdb I get: Glasgow Haskell Compiler, version 4.06, for Haskell 98, compiled by GHC version 4.06 Program received signal SIGSEGV, Segmentation fault. 0x90062010 in ?? () (gdb) bt #0 0x90062010 in ?? () #1 0xa7db74 in schedule () #2 0xa7e080 in waitThread () #3 0xa7c8a8 in rts_evalIO () #4 0xa7c2b8 in main () I'll keep the gdb session alive for the rest of today if you have any more queries.
Re: Segmentation Fault
On Tue, Jan 18, 2000 at 11:21:06 +0100, George Russell wrote: [...] OK, after hacking ghc-inplace to stop it deleting all its files (is there a --keep-everything option?) and running hsc inside gdb I get: [...] EXTRAHCFLAGS="-keep-hc-files-too" I dimly remember an option -keep-s-files-too ... Cheers, Michael -- Lehrstuhl-Gärtnerei Michael Weber [EMAIL PROTECTED] Lehrstuhl für Informatik II RWTH Aachen WWW: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/
Re: Segmentation Fault
Michael Weber wrote: On Tue, Jan 18, 2000 at 11:21:06 +0100, George Russell wrote: [...] OK, after hacking ghc-inplace to stop it deleting all its files (is there a --keep-everything option?) and running hsc inside gdb I get: [...] EXTRAHCFLAGS="-keep-hc-files-too" I dimly remember an option -keep-s-files-too ... Yes, both those options exist but they keep the products of hsc, not what goes into it. In this case, the cpp'd unlit'd source. I would like a -keep-everything flag to actually keep everything . . .
RE: Segmentation Fault
Michael Weber wrote: On Tue, Jan 18, 2000 at 11:21:06 +0100, George Russell wrote: [...] OK, after hacking ghc-inplace to stop it deleting all its files (is there a --keep-everything option?) and running hsc inside gdb I get: [...] EXTRAHCFLAGS="-keep-hc-files-too" I dimly remember an option -keep-s-files-too ... Yes, both those options exist but they keep the products of hsc, not what goes into it. In this case, the cpp'd unlit'd source. I would like a -keep-everything flag to actually keep everything . . . The "standard hack" here is to run 'ghc -v' and hit Ctrl-Z at the right moment. This is a trick that's been passed down from previous generations of GHC hackers, I guess no-one has ever been bothered enough to fix it properly... Cheers, Simon
RE: Segmentation Fault
George Russell ([EMAIL PROTECTED]) wrote: : This bug just won't go away, and I've tried everything, including upgrading to : gcc 2.95.2 and recompiling the 4.06 sources with the 4.04 binary release. : But whenever the latest version of 4.06 tries to compile itself the result is: : : ../../driver/ghc-inplace -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -O -split-objs -odir PrelBase -H20m -fcompiling-prelude -static -keep-hc-files-too -keep-s-files-too -H32m -K32m -H30m -O -O2-for-C -c PrelBase.lhs -o PrelBase.o -osuf o : Segmentation Fault : : I've managed to compile a smaller program with 4.06 (compiled from 4.04) without : problems. : : I am using Sparc/Solaris. Hi George, I reported a similar problem (also Sparc/Solaris) and haven't received any reply yet. I downgraded to gcc 2.8.1 and my problems were over. Regards, Marc van Dongen -- Marc van Dongen, CS Dept | phone: +353 21 903578 University College Cork, NUIC | Fax: +353 21 903113 College Road, Cork, Ireland | Email: [EMAIL PROTECTED] Our nightly build did a two-stage bootstrap last night on a Sparc/Solaris system successfully: ~/builds uname -a SunOS gigha 5.7 Generic_106541-04 sun4u sparc SUNW,Ultra-5_10 ~/builds gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs gcc version 2.95.2 19991024 (release) Stage 1 was build with 4.04pl1 (make sure you have pl1!), and stage 2 was bootstrapped. I've just done a stage 3 build too, which went through without a hitch. So I'm at a loss now: Marc reported that downgrading his gcc fixed the problem. That suggests that it's a gcc bug, but we're using 2.95.2 here without any difficulties. There's also the outstanding build problem related to sigset_t, which I also can't reproduce. Any insight appreciated. Cheers, Simon
