C inline externals with GEC

3 messages Options
Embed this post
Permalink
Colin Paul Adams

C inline externals with GEC

Reply Threaded More More options
Print post
Permalink
I've just managed to call a function written in Haskell from an Eiffel
program (by using C external inline) with ISE 6.3.

When I compile instead with gec, and run the program, I get a
segmentation fault.

Here is the backtrace from gdb:

(gdb) backtrace
#0  0x0000000000452fc0 in evacuate ()
#1  0x000000000043b7f8 in scavenge_static ()
#2  0x0000000000439ea4 in GarbageCollect ()
#3  0x00000000004351df in scheduleDoGC ()
#4  0x00000000004353da in exitScheduler ()
#5  0x00000000004345a2 in hs_exit_ ()
#6  0x000000000041900c in T21f3 (C=0x1971f80, a1=7) at fib1.c:1200
#7  0x00000000004191a8 in T21c10 () at fib1.c:1000
#8  0x0000000000419356 in main (argc=<value optimized out>, argv=<value optimized out>)
    at fib1.c:11616

hs_exit(0 is the function used to shutdown the Haskell runtime. So the
actual call to the Haskell function has worked. (I implemented
hs_exit() a a separate external - if I comment out the call to this
external, then the gec-compiled program works fine.

Looking at the backtrace, I notice the call to GarbageCollect (). I'm
assuming this is the Haskell garbage collector and not the boehm GC
that the gec-compiled program is using. Especially as I have done
nothing specifically to ask for GC from gec. I did have BOEHM_GC set,
but I unset it, did a geant clobber, followed by a geant compile_ge,
and the problem still persists.

Hm. I just tried the program again with a bigger argument (it's just
generating Fibonacci numbers) with the call to hs_exit commented
out. Now it crashes again, so presumably in the first case there was
no actual call to the Haskell garbage collector until the runtime
system was explicitly shutdown, whereas with the larger argument
(calculating the fibonacci number for 11199 does a fair bit of work -
using MA_DECIMAL instead of Haskell, the gec-compiled program takes
over 10 ms.) it is presumably having to do some garbage collecting
during the calculation.

I don't know if you can make any useful comments on this. Thinking
aloud, it might be something along the lines of gec is using ordinary
malloc(), in the absence of BoehmGC (is it?), whereas ISE might not be
using malloc at all (?? - this sounds most unlikely).

Any thoughts?
--
Colin Adams
Preston Lancashire

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
Colin Paul Adams

Re: C inline externals with GEC

Reply Threaded More More options
Print post
Permalink
I tried compiling in the boehm GC and the results are the same.
--
Colin Adams
Preston Lancashire

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop
Eric Bezault

Re: C inline externals with GEC

Reply Threaded More More options
Print post
Permalink
In reply to this post by Colin Paul Adams
Colin Paul Adams wrote:

> I've just managed to call a function written in Haskell from an Eiffel
> program (by using C external inline) with ISE 6.3.
>
> When I compile instead with gec, and run the program, I get a
> segmentation fault.
>
> Here is the backtrace from gdb:
>
> (gdb) backtrace
> #0  0x0000000000452fc0 in evacuate ()
> #1  0x000000000043b7f8 in scavenge_static ()
> #2  0x0000000000439ea4 in GarbageCollect ()
> #3  0x00000000004351df in scheduleDoGC ()
> #4  0x00000000004353da in exitScheduler ()
> #5  0x00000000004345a2 in hs_exit_ ()
> #6  0x000000000041900c in T21f3 (C=0x1971f80, a1=7) at fib1.c:1200
> #7  0x00000000004191a8 in T21c10 () at fib1.c:1000
> #8  0x0000000000419356 in main (argc=<value optimized out>, argv=<value optimized out>)
>     at fib1.c:11616
>
> hs_exit(0 is the function used to shutdown the Haskell runtime. So the
> actual call to the Haskell function has worked. (I implemented
> hs_exit() a a separate external - if I comment out the call to this
> external, then the gec-compiled program works fine.
>
> Looking at the backtrace, I notice the call to GarbageCollect (). I'm
> assuming this is the Haskell garbage collector and not the boehm GC
> that the gec-compiled program is using. Especially as I have done
> nothing specifically to ask for GC from gec. I did have BOEHM_GC set,
> but I unset it, did a geant clobber, followed by a geant compile_ge,
> and the problem still persists.
>
> Hm. I just tried the program again with a bigger argument (it's just
> generating Fibonacci numbers) with the call to hs_exit commented
> out. Now it crashes again, so presumably in the first case there was
> no actual call to the Haskell garbage collector until the runtime
> system was explicitly shutdown, whereas with the larger argument
> (calculating the fibonacci number for 11199 does a fair bit of work -
> using MA_DECIMAL instead of Haskell, the gec-compiled program takes
> over 10 ms.) it is presumably having to do some garbage collecting
> during the calculation.
>
> I don't know if you can make any useful comments on this. Thinking
> aloud, it might be something along the lines of gec is using ordinary
> malloc(), in the absence of BoehmGC (is it?), whereas ISE might not be
> using malloc at all (?? - this sounds most unlikely).
>
> Any thoughts?

I don't know how the Haskell GC works, so I cannot really help
you here.

Yes, gec uses ordinary malloc.

--
Eric Bezault
mailto:[hidden email]
http://www.gobosoft.com

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gobo-eiffel-develop mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gobo-eiffel-develop