[HELP] Debug segfault, maybe memory-leak based

[vincele]

Can someone help in deciphering the following segfault (Full backtrace attached)

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x1603383f40) at malloc.c:2929
2929	malloc.c: No such file or directory.
(gdb) bt
#0  __GI___libc_free (mem=0x1603383f40) at malloc.c:2929
#1  0x0000000000f6a7b0 in __gnu_cxx::new_allocator<GG::X>::deallocate (this=0x33596b0, __p=0x1603383f40)
    at /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/ext/new_allocator.h:110
#2  0x0000000000f6a780 in __gnu_cxx::__alloc_traits<std::allocator<GG::X> >::deallocate (__a=..., __p=0x1603383f40, 
    __n=18446744050087231520) at /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/ext/alloc_traits.h:185
#3  0x0000000000f6a70e in std::_Vector_base<GG::X, std::allocator<GG::X> >::_M_deallocate (this=0x33596b0, __p=0x1603383f40, 
    __n=18446744050087231520) at /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/stl_vector.h:178
#4  0x0000000000f6a699 in std::_Vector_base<GG::X, std::allocator<GG::X> >::~_Vector_base (this=0x33596b0)
    at /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/stl_vector.h:160
#5  0x0000000000f6a5e2 in std::vector<GG::X, std::allocator<GG::X> >::~vector (this=0x33596b0)
    at /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/stl_vector.h:425
#6  0x00007ffff067774c in GG::Font::TextElement::~TextElement (this=0x3359690)
    at /home/vince/repo/upstream/FreeOrion-llvm/GG/src/Font.cpp:533
#7  0x00007ffff0696a1b in GG::Font::FormattingTag::~FormattingTag (this=0x3359690)
    at /home/vince/repo/upstream/FreeOrion-llvm/GG/GG/Font.h:238
#8  0x00007ffff0696a78 in GG::Font::FormattingTag::~FormattingTag (this=0x3359690)
    at /home/vince/repo/upstream/FreeOrion-llvm/GG/GG/Font.h:238
[...]
#19 0x00007ffff07d73b5 in GG::TextControl::~TextControl (this=0x3358740)
    at /home/vince/repo/upstream/FreeOrion-llvm/GG/src/TextControl.cpp:57
#20 0x00000000011f49d9 in LinkText::~LinkText (this=0x3358740) at /home/vince/repo/upstream/FreeOrion-llvm/UI/LinkText.h:119
#21 0x00000000011f4a58 in LinkText::~LinkText (this=0x3358740) at /home/vince/repo/upstream/FreeOrion-llvm/UI/LinkText.h:119
#22 0x00007ffff081eef9 in GG::Wnd::DeleteChildren (this=0x343ef70) at /home/vince/repo/upstream/FreeOrion-llvm/GG/src/Wnd.cpp:611
#23 0x00007ffff081eac0 in GG::Wnd::~Wnd (this=0x343ef70) at /home/vince/repo/upstream/FreeOrion-llvm/GG/src/Wnd.cpp:232
#24 0x0000000000efb485 in GG::Control::~Control (this=0x343ef70) at /home/vince/repo/upstream/FreeOrion-llvm/GG/GG/Control.h:48
#25 0x0000000001403187 in (anonymous namespace)::SitRepDataPanel::~SitRepDataPanel (this=0x343ef70)
    at /home/vince/repo/upstream/FreeOrion-llvm/UI/SitRepPanel.cpp:145
#26 0x00000000014031d8 in (anonymous namespace)::SitRepDataPanel::~SitRepDataPanel (this=0x343ef70)
    at /home/vince/repo/upstream/FreeOrion-llvm/UI/SitRepPanel.cpp:145
#27 0x00007ffff081eef9 in GG::Wnd::DeleteChildren (this=0x343d9f0) at /home/vince/repo/upstream/FreeOrion-llvm/GG/src/Wnd.cpp:611
#28 0x00007ffff081eac0 in GG::Wnd::~Wnd (this=0x343d9f0) at /home/vince/repo/upstream/FreeOrion-llvm/GG/src/Wnd.cpp:232
#29 0x00007ffff0749f53 in GG::Layout::~Layout (this=0x343d9f0) at /home/vince/repo/upstream/FreeOrion-llvm/GG/GG/Layout.h:103
#30 0x00007ffff074a028 in GG::Layout::~Layout (this=0x343d9f0) at /home/vince/repo/upstream/FreeOrion-llvm/GG/GG/Layout.h:103
#31 0x00007ffff081eef9 in GG::Wnd::DeleteChildren (this=0x33894a0) at /home/vince/repo/upstream/FreeOrion-llvm/GG/src/Wnd.cpp:611
#32 0x00007ffff081eac0 in GG::Wnd::~Wnd (this=0x33894a0) at /home/vince/repo/upstream/FreeOrion-llvm/GG/src/Wnd.cpp:232
#33 0x0000000000efb485 in GG::Control::~Control (this=0x33894a0) at /home/vince/repo/upstream/FreeOrion-llvm/GG/GG/Control.h:48
#34 0x00007ffff075440c in GG::ListBox::Row::~Row (this=0x33894a0) at /home/vince/repo/upstream/FreeOrion-llvm/GG/src/ListBox.cpp:224
#35 0x0000000001402ff5 in (anonymous namespace)::SitRepRow::~SitRepRow (this=0x33894a0)
    at /home/vince/repo/upstream/FreeOrion-llvm/UI/SitRepPanel.cpp:235
#36 0x0000000001403018 in (anonymous namespace)::SitRepRow::~SitRepRow (this=0x33894a0)
    at /home/vince/repo/upstream/FreeOrion-llvm/UI/SitRepPanel.cpp:235
#37 0x00007ffff081eef9 in GG::Wnd::DeleteChildren (this=0x20b2840) at /home/vince/repo/upstream/FreeOrion-llvm/GG/src/Wnd.cpp:611
#38 0x00007ffff075d199 in GG::ListBox::Clear (this=0x20b2840) at /home/vince/repo/upstream/FreeOrion-llvm/GG/src/ListBox.cpp:810
#39 0x00000000014005d9 in SitRepPanel::Update (this=0x20b10b0) at /home/vince/repo/upstream/FreeOrion-llvm/UI/SitRepPanel.cpp:522
#40 0x00000000013fed68 in SitRepPanel::PrevClicked (this=0x20b10b0)
    at /home/vince/repo/upstream/FreeOrion-llvm/UI/SitRepPanel.cpp:361
#41 0x0000000001408a32 in boost::_mfi::mf0<void, SitRepPanel>::operator() (this=0x20b80f0, p=0x20b10b0)
    at /usr/include/boost/bind/mem_fn_template.hpp:49
[...]

I was testing the sitrep filtering patch, by going forward and then backward through them, and got that SegF...

Memory usage was huge (all my swap consumed) so it may be memleak induced...

How do I get to find the culprit of this ?

FO-segf-memleak.txt

(31.21 KiB) Downloaded 83 times

[vincele]

Admin : please delete this post. I'm not seeing that segfault any more, perhaps because of a svn update, or any other thing that can make heisenbugs...

[Geoff the Medio]

I'd rather keep spurious bug reports around, in case they recur.

You clicked the previous button in the sitrep panel, which triggered an update of the shown sitreps. This cleared the ListBox, which deleted one or more ListBox::Row, which deleted the child Wnd of that row, which include a LinkText object, which is a TextControl. This caused a Font::FormattingTag object to be deleted, which includes a TextElement object, which contains a vector<GG::X>. The crash happened in the new_allocator<GG::X>::deallocate function. The TextElement::widths vector<GG::X> appears to be managed automatically, not appearing explicitly in the TextElement constructor or destructor, so perhaps something higher up in the chain was double-deleted somehow? Or got set up in a weird state by you manipulating the UI at the same time as an update came in from the server and changed the available sitreps in another thread? Some exclusion guards to prevent that might be useful here, and possibly elsewhere in the UI.