[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help needed debugging segfault with Guile 1.8.7

From: Peter TB Brett
Subject: Re: Help needed debugging segfault with Guile 1.8.7
Date: Tue, 30 Nov 2010 19:43:55 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Neil Jerram <address@hidden> writes:

> [snip]
> I think your design is similar to what is outlined in the `Extending
> Dia' node of the Guile manual.  Were you aware of that doc before
> working out your design?  If not, I guess we need to make it more
> prominent.  If yes, I'd appreciate any suggestions you have for how it
> may be improved.

I wasn't aware of that document, despite using the Guile Manual every
day!  Could I please suggest that filing it under "Programming Overview"
probably isn't the best place for it?

I think it should be highlighted that adding a Guile-specific field to
dia_shape (or its equivalent) may not always be possible, e.g. if Guile
is just one of several language bindings.

>> So, where was the bug?  When a smob is GC'd, and if the pointer it
>> contains hasn't already been cleared, [...]
> Now that you've successfully debugged this, is there any general
> advice that you would offer for "how to investigate a free list
> corruption?"  I would guess not, as corruption is fundamentally a
> general thing and has infinite possible causes - but perhaps I'm
> missing something.

One thing that would have been *AWESOME* is if Guile 1.8.x's GC had used
the macros defined in Valgrind's `memcheck.h' (which is BSD licensed
IIRC).  It would make running programs with libguile under Valgrind so
much more useful, and would have *instantly* highlighted what was going
wrong with my code -- it would probably have saved me a couple of days
of beating my head against what turned out to be a really simple bug.
(There's literally no runtime overhead if a program's not being run
under Valgrind).

>> I hope that explained things reasonably precisely!
> Thank you, it certainly did.  To conclude, I'll just note that in the
> Guile 2.0 future we won't have such difficult problems, because of
> using libgc - which will automatically find active references anywhere
> in the whole application.  (And of course I understand that your code
> still needs to work with Guile 1.8.x now.)

Thanks for the info.  Judging by previous experience, gEDA will need to
support Guile 1.8.x for at least two years after Guile 2.x arrives.
It's probably going to be painful. :-/


Peter Brett <address@hidden>
Remote Sensing Research Group
Surrey Space Centre

Attachment: pgpb4x6nVZ3Fw.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]