[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19883: Correction for backtrace
From: |
Ludovic Courtès |
Subject: |
bug#19883: Correction for backtrace |
Date: |
Thu, 26 Feb 2015 12:35:32 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) |
David Kastrup <address@hidden> skribis:
> address@hidden (Ludovic Courtès) writes:
>
>> David Kastrup <address@hidden> 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’.
- bug#19883: Smob's mark_smob has become unreliable in Guile 2.x, David Kastrup, 2015/02/16
- bug#19883: Correction for backtrace, David Kastrup, 2015/02/16
- bug#19883: Correction for backtrace, Ludovic Courtès, 2015/02/25
- bug#19883: Correction for backtrace, David Kastrup, 2015/02/25
- bug#19883: Correction for backtrace,
Ludovic Courtès <=
- bug#19883: Correction for backtrace, David Kastrup, 2015/02/26
- bug#19883: Correction for backtrace, Ludovic Courtès, 2015/02/26
- bug#19883: Correction for backtrace, David Kastrup, 2015/02/26
- bug#19883: Correction for backtrace, Ludovic Courtès, 2015/02/26
- bug#19883: Correction for backtrace, David Kastrup, 2015/02/26
- bug#19883: Correction for backtrace, Ludovic Courtès, 2015/02/27
- bug#19883: Correction for backtrace, David Kastrup, 2015/02/27