Re: Latest guile 1.9 segfault in GC

2010-08-24 Thread Ludovic Courtès
Hi Cédric, Cedric Cellier writes: > 1.9.11 version still seams a bit slower than 1.8.7, At doing what? Is there a minimal test case you could post? > most of the time being spent in vm_debug_engine, That’s the bytecode interpreter, so it’s expected. :-) > malloc and free. That’s more surp

Re: Latest guile 1.9 segfault in GC

2010-08-23 Thread Cedric Cellier
-[ Wed, Aug 18, 2010 at 09:16:15AM -0700, Andy Wingo ] > You're probably not hitting the compiler for some reason. I think that > scm_primitive_load doesn't support autocompilation, where it probably > should. Is that the function you're using to load your Scheme code? Ok, the file I load with

Re: Latest guile 1.9 segfault in GC

2010-08-20 Thread rixed
> Guile 1.9's interpreter is slower than 1.8's interpreter, but 1.9 has a > compiler, and compiled Scheme runs much faster than 1.8. "much faster" is very nice to hear ! > You're probably not hitting the compiler for some reason. (...) > To work around it for now, call `load' from scheme. I know

Re: Latest guile 1.9 segfault in GC

2010-08-18 Thread Andy Wingo
Hi Cedric, On Tue 17 Aug 2010 07:08, Cedric Cellier writes: > As a side note, I find libguile 1.9 slower than libguile 1.8.7. > I suppose, being an unstable version, it's compiled by default > with many debug options on. Is there an easy way to configure it > for fast execution, for benchmarking

Re: Latest guile 1.9 segfault in GC

2010-08-18 Thread Ludovic Courtès
Hi, Cedric Cellier writes: > But finaly, thanks to libgc's debug message, I got it. > Actually, libgc overwrite pthread_create (and pthread_sigmask, > and a few more) to know when a new thread is started. > But this overloading is done "softly", ie. by a define in a > C header file. [...] > So

Re: Latest guile 1.9 segfault in GC

2010-08-18 Thread Ludovic Courtès
Hi! Cedric Cellier writes: > I do not understand how this GC works, but find it strange that this global > variable is changed like this, especially since the libgc gc.h reads : > "GC_all_interior_pointers (...) May not be changed after GC initialization." ‘scm_storage_prehistory’ does that in

Re: Latest guile 1.9 segfault in GC

2010-08-17 Thread Cedric Cellier
Ok, this bug was fixed but not the actual bug I was after. But finaly, thanks to libgc's debug message, I got it. Actually, libgc overwrite pthread_create (and pthread_sigmask, and a few more) to know when a new thread is started. But this overloading is done "softly", ie. by a define in a C heade

Re: Latest guile 1.9 segfault in GC

2010-08-17 Thread Cedric Cellier
I'm using libgc v 7.2alpha4. Apparently the value of GC_all_interior_pointers is 1 when initializing the GC (so GC_old_normal_bl is not initialized) and suddenly is set to 1 so that the next call to GC_is_black_listed dereference it and thus crash. It's set to 0 by scm_storage_prehistory in ligui

Latest guile 1.9 segfault in GC

2010-08-17 Thread Cedric Cellier
% cat main.c #include #include #include pthread_t dumper; static void *call_gc(void *null) { scm_gc(); return NULL; } void *thread_dumper(void *null) { scm_with_guile(call_gc, NULL); return NULL; } int main(void) { while (1) { pthread_create(&dumper, NULL, t