interfacing with a boehm-gc library from XS

davidnicol has asked for the wisdom of the Perl Monks concerning the following question:

Update: after installing a 5.8.8 built from source (Configure -d) my test programs are now running to their ends without crashing.

So I'm trying to write an XS wrapper (using Inline::C, which greatly simplifies the task) for a library that uses boehm GC -- GC_malloc and all that -- and every time I run it it segfaults in a different place. Even after disabling the garbage collection, so it's not a gc-throwing-away-memory-it-doesn't-know-about kind of problem, (unless it still is) Now I'm getting segfaults inside things that I _KNOW_ are robust, such as

gdb) where
#0  0x00a3e41d in memmove () from /lib/libc.so.6
#1  0x078122c1 in Perl_sv_catpvn_flags () from /usr/lib/perl5/5.8.6/i3
+86-linux-thread-multi/CORE/libperl.so
#2  0x07816196 in Perl_sv_catsv_flags () from /usr/lib/perl5/5.8.6/i38
+6-linux-thread-multi/CORE/libperl.so
#3  0x0784eaf4 in Perl_do_join () from /usr/lib/perl5/5.8.6/i386-linux
+-thread-multi/CORE/libperl.so
#4  0x077fcaca in Perl_pp_join () from /usr/lib/perl5/5.8.6/i386-linux
+-thread-multi/CORE/libperl.so
#5  0x077e4b01 in Perl_runops_debug () from /usr/lib/perl5/5.8.6/i386-
+linux-thread-multi/CORE/libperl.so
#6  0x07792b9e in Perl_get_cv () from /usr/lib/perl5/5.8.6/i386-linux-
+thread-multi/CORE/libperl.so
#7  0x07797045 in Perl_call_sv () from /usr/lib/perl5/5.8.6/i386-linux
+-thread-multi/CORE/libperl.so
#8  0x07799517 in Perl_call_method () from /usr/lib/perl5/5.8.6/i386-l
+inux-thread-multi/CORE/libperl.so
#9  0x077ef199 in Perl_magic_setnkeys () from /usr/lib/perl5/5.8.6/i38
+6-linux-thread-multi/CORE/libperl.so
#10 0x077ef5fc in Perl_magic_setpack () from /usr/lib/perl5/5.8.6/i386
+-linux-thread-multi/CORE/libperl.so
#11 0x077ed7ee in Perl_mg_set () from /usr/lib/perl5/5.8.6/i386-linux-
+thread-multi/CORE/libperl.so
#12 0x077fba16 in Perl_pp_sassign () from /usr/lib/perl5/5.8.6/i386-li
+nux-thread-multi/CORE/libperl.so
#13 0x077e4b01 in Perl_runops_debug () from /usr/lib/perl5/5.8.6/i386-
+linux-thread-multi/CORE/libperl.so
#14 0x07797f51 in perl_run () from /usr/lib/perl5/5.8.6/i386-linux-thr
+ead-multi/CORE/libperl.so
#15 0x080493f4 in main ()
[download]

on the fourth time through a loop that worked right the first three times. Does anyone have experience with wrapping XS around a library managed with gc, who can offer some advice? Do I have to reimplement the GC interface in terms of SVPVX and make my library link against that instead of libgc? Is libgc somehow interfering with perl's malloc, or is perls malloc somehow playing fast-and-loose in such a way that GC_malloc and it are stepping on each others toes? I've got 5.8.6 -- I guess I'll build a 5.8.8 and see if that does anything for me while waiting for notification of responses.

Comment on interfacing with a boehm-gc library from XS Download Code

Replies are listed 'Best First'.
Re: interfacing with a boehm-gc library from XS by Zaxo (Archbishop) on Apr 22, 2006 at 00:07 UTC
I don't have a specific solution for you, just some observations. The segfaults you see are almost certainly from double-freeing chunks of memory. Perl has its own memory management - in two flavors. One uses native malloc/free, the other a version provided by perl. Both are closely tied in to how perl provides storage to variables and and decides when it can take it back. Your specific questions say you already appreciate the trouble this may cause. You will probably need to carefully work both mm models in parallel, with two mallocs, two frees, and a separate memory arena for libgc-managed storage. You'll need to keep track of which pointers come from which. The perlguts and perlapi docs will help a lot with the perl end. This kind of problem often occurs with libraries for complex data structures, but I've never tried hooking up to a whole different memory managment scheme. Good luck! After Compline, Zaxo	[reply]
Re: interfacing with a boehm-gc library from XS by creamygoodness (Curate) on Apr 22, 2006 at 16:53 UTC
Have you tried running this under Valgrind? Have you inspected the C code that Inline C is generating and is it doing what you expect? -- Marvin Humphrey Rectangular Research ― http://www.rectangular.com	[reply]