RE: Segmentation Fault

[Simon Marlow]

> 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

Re: Segmentation Fault

[George Russell]

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

[Michael Weber]

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

[George Russell]

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

[Simon Marlow]

> 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

[Simon Marlow]

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 in Gtk2Hs callbacks

[Simon Marlow]

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/access violation in generated code

[Bas van Dijk]

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/access violation in generated code

[Ian Lynagh]

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

[Bas van Dijk]

On 23 June 2012 02:40, Ian Lynagh  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 in non-dynamically linked binaries?

[Simon Marlow]

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 later
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:
...
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  0x0

Re: Segmentation fault in non-dynamically linked binaries?

[austin seipp]

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  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 
> Date: Wed, Jun 16, 2010 at 11:21 AM
> Subject: Re: Segmentation fault in non-dynamically linked binaries?
> To: Simon Marlow 
>
>
> 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 :        xor    %ebp,%ebp
> 0x00432a28 :        nopl   0x0(%rax,%rax,1)
> 0x00432a30 :        mov    (%r14,%rbp,1),%rdi
> 0x00432a34 :        mov    %rbp,%rbx
> 0x00432a37 :        add
> 0x247f5a(%rip),%rbx        # 0x67a998 
> 0x00432a3e :        add    $0x1,%r12d
> 0x00432a42 :        callq  0x4028b8 
> 0x00432a47 :        lea    0x1(%rax),%edi
> 0x00432a4a :        mov    $0x4616fe,%esi
> 0x00432a4f :        callq  0x434790 
> 
> 0x00432a54 :       mov    %rax,(%rbx)
> 0x00432a57 :       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
> 
> 0x00432dce <+78>:       add    $0x1,%r12d
> 0x00432dd2 <+82>:       callq  0x67b3c0 
> 0x00432dd7 <+87>:       lea    0x1(%rax),%edi
> 0x00432dda <+90>:       mov    $0x46207e,%esi
> 0x00432ddf <+95>:       callq  0x434cb0 
> 0x00432de4 <+100>:      mov    %rax,(%rbx)
> 0x00432de7 <+103>:      mov    0x24896a(%rip),%rax        #
> 0x67b758 
> ...
>
> 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  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.
>&g

Re: Segmentation fault trying to build ghc 6.10.1 using macports, Mac OS X 10.5, PPC

[Gregory Wright]

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 
and .


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

[Christian Maeder]

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 
> and .
> 
> 
> 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]

On Mon, Feb 2, 2009 at 9:58 AM, Gregory Wright  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 

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users