bug-guile
[Top][All Lists]
Advanced

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

bug#19883: Correction for backtrace


From: David Kastrup
Subject: bug#19883: Correction for backtrace
Date: Thu, 26 Feb 2015 00:17:27 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

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.

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





reply via email to

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