GNU bug report logs - #19883
Smob's mark_smob has become unreliable in Guile 2.x

Previous Next

Full log

Message #17 received at 19883 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: David Kastrup <dak <at> gnu.org>
Cc: 19883 <at> debbugs.gnu.org
Subject: Re: bug#19883: Correction for backtrace
Date: Thu, 26 Feb 2015 12:35:32 +0100

David Kastrup <dak <at> gnu.org> skribis:

> ludo <at> gnu.org (Ludovic Courtès) writes:
>
>> David Kastrup <dak <at> gnu.org> skribis:
>>
>>> This is embarrassing: I used the wrong executable in connection with the
>>> core dump.  With the matching executable, the coredump makes a lot more
>>> sense:
>>>
>>> #0  0x00000000 in ?? ()
>>> #1  0x0804aee0 in Smob_base<Family>::mark_trampoline (arg=0x9fbb000)
>>>     at smobs.tcc:34
>>> #2  0xb761b2da in ?? () from /usr/lib/libguile-2.0.so.22
>>> #3  0xb72751f8 in GC_mark_from () from /usr/lib/i386-linux-gnu/libgc.so.1
>>
>> Could you try commenting out all the SMOB mark functions in LilyPond?
>>
>> This doesn’t fix the bug, of course, but it’s probably a good
>> workaround: user-provided mark functions are not needed in Guile 2.0
>> since libgc scans the whole heap for live pointers.
>
> Even the test program crashes at the end (when `count' is called in
> order to traverse the created hierarchy) when you disable the setting of
> the mark function in the init method in smobs.tcc.

Could you add debugging symbols for libguile?  I don’t understand how
‘count’ gets called.

Do you know if this is a use-after-free error?  Perhaps setting
MALLOC_CHECK_=1 would give a hint.

If this is the case, Andy had the idea of turning on topological
finalization in the GC.  This may help for this particular case, but I
vaguely recall that this breaks other finalizer-related things.

(I would check by myself, but ISTR that building LilyPond “on one’s own”
is not recommended.  What would you suggest?  A Guix recipe would be
sweet.)

> A pointer to a C++ structure does not appear to protect the
> corresponding SMOB data and free_smob calls the delete operator which
> calls destructors and clobbers the memory area.

Oh, I was mistaken in my previous message.  GC scans the stack and the
GC-managed heap (stuff allocated with GC_MALLOC/scm_gc_malloc et al.),
but it does *not* scan the malloc/new heap.

So indeed, C++ objects that hold references to ‘SCM’ objects, such as
instances of ‘Smob<X>’, must either have a mark function, or they must
be allocated with scm_gc_malloc.

Would it be possible to add a ‘new’ operator to ‘Smob’ that uses
‘scm_gc_malloc’, and a ‘delete’ operator that uses ‘scm_gc_free’?

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.