Fwd: FFI and ghci
marlowsd at gmail.com
Mon Dec 7 04:14:11 EST 2009
On 05/12/2009 13:53, Patrick LeBoutillier wrote:
> I sent this question to haskell-cafe, realizing later that perhaps
> this list is a better place for it.
> ---------- Forwarded message ----------
> From: Patrick LeBoutillier<patrick.leboutillier at gmail.com>
> Date: Fri, Dec 4, 2009 at 2:09 PM
> Subject: FFI and ghci
> To: Haskell Cafe<haskell-cafe at haskell.org>
> Hi all,
> I have a small FFI-based library that I like to test like this:
> $ ghci -I../c -L../c/.libs -lmlp t.hs
> GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Please upgrade to 6.10.4, lots of bugs were fixed.
> Loading package ghc-prim ... linking ... done.
> Loading package integer ... linking ... done.
> Loading package base ... linking ... done.
> Loading object (dynamic) mlp ... done
> final link ... done
> [1 of 9] Compiling MLP ( MLP.hs, interpreted )
> [2 of 9] Compiling MLP.Error ( MLP/Error.hs, interpreted )
> [3 of 9] Compiling MLP.Context ( MLP/Context.hs, interpreted )
> [4 of 9] Compiling MLP.Runtime ( MLP/Runtime.hs, interpreted )
> [5 of 9] Compiling MLP.Object ( MLP/Object.hs, interpreted )
> [6 of 9] Compiling MLP.Type ( MLP/Type.hs, interpreted )
> [7 of 9] Compiling MLP.Value ( MLP/Value.hs, interpreted )
> [8 of 9] Compiling MLP.Language ( MLP/Language.hs, interpreted )
> [9 of 9] Compiling Main ( t.hs, interpreted )
> Ok, modules loaded: MLP, MLP.Object, Main, MLP.Runtime, MLP.Context,
> MLP.Error, MLP.Value, MLP.Type, MLP.Language.
> *Main> main
> Note: Inside libmlp.so, another shared object is loaded using dlopen().
> When running this test program I get some sporadic segmentation
> faults, which seem to always occur at entrypoint to the
> shared object that is loaded with dlopen().
> But when I compile it with ghc, i.e.
> $ ghc --make -I../c -L../c/.libs -lmlp t.hs
> I can't reproduce crash.
> Can anyone see why this could be happening? It's quite possible that
> there is really a bug in the C code,
> but if someone knows about a bug or something in ghci that can cause
> this behaviour I can stop looking...
This one might apply if you're on x86-64:
other than that, nothing springs to mind. If you can narrow it down to
a small(er) test case and submit a bug report, we'll try to take a look.
More information about the Glasgow-haskell-users