David Kastrup <d...@gnu.org> skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> David Kastrup <d...@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’.
