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.
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.
Program received signal SIGSEGV, Segmentation fault.
0x08049b0a in std::vector<Family*, std::allocator<Family*> >::size (
this=0x1b8b) at /usr/include/c++/4.9/bits/stl_vector.h:655
655 { return size_type(this->_M_impl._M_finish -
this->_M_impl._M_start); }
(gdb) bt
#0 0x08049b0a in std::vector<Family*, std::allocator<Family*> >::size (
this=0x1b8b) at /usr/include/c++/4.9/bits/stl_vector.h:655
#1 0x08049498 in Family::count (this=0x1b7f) at test.cc:53
#2 0x0804947c in Family::count (this=0x834f350) at test.cc:54
#3 0x0804947c in Family::count (this=0x8297d40) at test.cc:54
#4 0x0804947c in Family::count (this=0x828a9f8) at test.cc:54
#5 0x0804947c in Family::count (this=0x817d768) at test.cc:54
#6 0x0804947c in Family::count (this=0x828d588) at test.cc:54
#7 0x0804947c in Family::count (this=0x83298b8) at test.cc:54
#8 0x0804947c in Family::count (this=0x817fe58) at test.cc:54
#9 0x080495df in workload (avv=0xbffff074) at test.cc:73
#10 0xb7e66dfd in ?? () from /usr/lib/libguile-2.0.so.22
#11 0xb7ef08e7 in ?? () from /usr/lib/libguile-2.0.so.22
#12 0xb7ec9fb9 in ?? () from /usr/lib/libguile-2.0.so.22
#13 0xb7f08f20 in ?? () from /usr/lib/libguile-2.0.so.22
#14 0xb7f09539 in ?? () from /usr/lib/libguile-2.0.so.22
#15 0xb7e714f3 in scm_call_4 () from /usr/lib/libguile-2.0.so.22
#16 0xb7ef0acf in scm_catch_with_pre_unwind_handler ()
from /usr/lib/libguile-2.0.so.22
#17 0xb7ef0bd4 in scm_c_catch () from /usr/lib/libguile-2.0.so.22
#18 0xb7e675d1 in ?? () from /usr/lib/libguile-2.0.so.22
#19 0xb7e676d3 in scm_c_with_continuation_barrier ()
from /usr/lib/libguile-2.0.so.22
#20 0xb7eedf7e in ?? () from /usr/lib/libguile-2.0.so.22
#21 0xb7b272c1 in GC_call_with_stack_base ()
from /usr/lib/i386-linux-gnu/libgc.so.1
#22 0xb7eee3e6 in scm_with_guile () from /usr/lib/libguile-2.0.so.22
#23 0x08049685 in main (ac=4, av=0xbffff074) at test.cc:85
--
David Kastrup
