Re: Help needed debugging segfault with Guile 1.8.7

2010-11-11 Thread rixed
General 2cents: If you have multiple guile scheme, don't. If you keep any SCM value across a call to scm_function(), protect it from the GC.

Re: Help needed debugging segfault with Guile 1.8.7

2010-11-11 Thread Neil Jerram
Peter TB Brett writes: > I'd really appreciate any suggestions that anyone might be able to give > me on figuring out how I've managed to break things. At the moment, I'm > at a complete loss. I'm afraid I only have two general ideas. 1. You can use gdb_print and gdb_output to see the Scheme v

Re: Help needed debugging segfault with Guile 1.8.7

2010-11-11 Thread Peter Brett
Peter TB Brett writes: > Peter TB Brett writes: >> I'd really appreciate any suggestions that anyone might be able to give >> me on figuring out how I've managed to break things. At the moment, I'm >> at a complete loss. > > So far, as far as I can tell the problem is due to freelist corruptio

Re: Help needed debugging segfault with Guile 1.8.7

2010-11-11 Thread Thien-Thi Nguyen
() Peter Brett () Thu, 11 Nov 2010 10:52:41 + stupid logic error in some weak ref management code Could you please describe this error?

Re: Help needed debugging segfault with Guile 1.8.7

2010-11-11 Thread Ludovic Courtès
Hi, Can you try to compile Guile with CPPFLAGS=-DSCM_DEBUG=1? It might report the problem before it hits. Thanks, Ludo’.

Re: Help needed debugging segfault with Guile 1.8.7

2010-11-11 Thread Peter Brett
Thien-Thi Nguyen writes: > () Peter Brett > () Thu, 11 Nov 2010 10:52:41 + > >>stupid logic error in some weak ref management code > > Could you please describe this error? > Sure. libgeda uses direct management of memory, and the structures used in its document object model need to be

Re: make-c-struct type support

2010-11-11 Thread Ludovic Courtès
Hello! l...@gnu.org (Ludovic Courtès) writes: > Tristan Colgate writes: > >> Does make-c-struct support poitners, long-integer and integer types? >> A brief grok of the code suggests not. How would one go about >> supporting it in a 32/64 bit agnostic manner? > > The following patch (not commi