Problem with garbage collector

[Joris van Rantwijk]

Hello,

This is a little off-topic. I tried to use Shed Skin but I can't get
the garbage collector to work.
My compiled Python program crashes immediately on startup:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf74866c0 (LWP 29979)]
0xf775e39d in GC_mark_from () from /usr/lib/libgc.so.1
(gdb) bt
#0 0xf775e39d in GC_mark_from () from /usr/lib/libgc.so.1
#1 0xf775eb90 in GC_mark_some () from /usr/lib/libgc.so.1
#2 0xf77566db in GC_stopped_mark () from /usr/lib/libgc.so.1
#3 0xf7756a8c in GC_try_to_collect_inner () from /usr/lib/libgc.so.1
#4 0xf7760b6e in GC_init_inner () from /usr/lib/libgc.so.1
#5 0xf775be46 in GC_generic_malloc_inner () from /usr/lib/libgc.so.1
#6 0xf775bf45 in GC_generic_malloc () from /usr/lib/libgc.so.1
#7 0xf775c1a7 in GC_malloc () from /usr/lib/libgc.so.1
#8 0x0804d7d5 in __shedskin__::__init ()
#9 0x08065d16 in main ()

In fact it looks like this has nothing to do with Shed Skin, because
the following tiny C++ program also segfaults:

#include <gc/gc_allocator.h>
#include <gc/gc_cpp.h>
class aap : public gc { };
int main(void) {
GC_INIT();
aap *a = new aap;
return 0;
}

So something is wrong with the garbage collector, but I'm too stupid
to figure it out. Does anybody here have a clue?

I'm using GCC 4.3.2 with libgc 6.8, running a 32-bit Debian lenny
system on Linux 2.6.32-rc5 x86_64.

Thanks, Joris.

[srepmub]

hi joris,

thanks for asking! I haven't really seen this problem before, only
some random crashes on FreeBSD, which could be avoided by disabling
threads. so I can only give some possibly useless suggestions, which
mostly involve building libgc yourself:

-download and install libgc 7.1, which may contain some fix for this
(6.8 is getting old, though ubuntu comes with it too, and it doesn't
have any problems)
-run the test set, which I think happens automatically when you build
the thing
-you could try ./configure --disable-threads to see if that helps
-does the C interface give you crashes as well?
-if the C interface works fine, possibly --enable-cplusplus might
help?
-define GC_DEBUG in the top of your program (getting a bit desperate
now)
-it also cannot hurt to use --enable-large-config


thanks again,
mark.

[Joris van Rantwijk]

On Nov 23, 1:21 pm, srepmub <mark.duf...@gmail.com> wrote:
> -does the C interface give you crashes as well?

Good point. Yes, it crashes also with C on the very first call to
GC_malloc().
The gc-7.1 test set also spews segfaults.

I now suspect that the problem is caused by my 64-bit kernel / 32-bit
userland combination. Although this is in my opinion a very sensible
configuration, it seems that I'm one of the few people using this.
I've reported it to the libgc author.

LibGC works fine one a pure x86_64 system though. Which means that I
can now run Shed Skin code!!

Joris.

[srepmub]

thanks for looking into this and reporting to libgc! please let me
know if there are any reactions.

did you benchmark the compiled mwmatching.py yet?

I have an idea to improve type inference scalability enough so the
original program may compile (after relocating the nested functions,
that is), but I won't be able to work on this in the next few weeks..


thanks,
mark.