Crash in eeschema adding a symbol and zoom crash

Bug #1823543 reported by Nick Østergaard on 2019-04-07
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Jon Evans

Bug Description

I have tried to attach the coredump, but the stack trace looks like this:

(gdb) bt
#0 0x00007f2d80d6021a in SCH_COMPONENT::IsInNetlist() const (this=0x55f2f58b3dd0) at /home/nickoe/kicad-source-mirror/eeschema/sch_component.cpp:1821
#1 0x00007f2d80c9a3d3 in CONNECTION_SUBGRAPH::ResolveDrivers(bool) (this=0x55f2dc17a900, aCreateMarkers=false) at /home/nickoe/kicad-source-mirror/eeschema/connection_graph.cpp:79
#2 0x00007f2d80c9c86a in CONNECTION_GRAPH::<lambda()>::operator()(void) const (__closure=0x55f2f5b9acf8) at /home/nickoe/kicad-source-mirror/eeschema/connection_graph.cpp:685
#3 0x00007f2d80ca5ba3 in std::__invoke_impl<void, CONNECTION_GRAPH::buildConnectionGraph()::<lambda()> >(std::__invoke_other, CONNECTION_GRAPH::<lambda()> &&) (__f=...) at /usr/include/c++/8.2.1/bits/invoke.h:60
#4 0x00007f2d80ca58c8 in std::__invoke<CONNECTION_GRAPH::buildConnectionGraph()::<lambda()> >(CONNECTION_GRAPH::<lambda()> &&) (__fn=...) at /usr/include/c++/8.2.1/bits/invoke.h:95
#5 0x00007f2d80ca6d88 in std::thread::_Invoker<std::tuple<CONNECTION_GRAPH::buildConnectionGraph()::<lambda()> > >::_M_invoke<0>(std::_Index_tuple<0>) (this=0x55f2f5b9acf8) at /usr/include/c++/8.2.1/thread:244
#6 0x00007f2d80ca6d49 in std::thread::_Invoker<std::tuple<CONNECTION_GRAPH::buildConnectionGraph()::<lambda()> > >::operator()(void) (this=0x55f2f5b9acf8) at /usr/include/c++/8.2.1/thread:253
#7 0x00007f2d80ca6d1e in std::thread::_State_impl<std::thread::_Invoker<std::tuple<CONNECTION_GRAPH::buildConnectionGraph()::<lambda()> > > >::_M_run(void) (this=0x55f2f5b9acf0) at /usr/include/c++/8.2.1/thread:196
#8 0x00007f2da1bee063 in std::execute_native_thread_routine(void*) (__p=0x55f2f5b9acf0) at /build/gcc/src/gcc/libstdc++-v3/src/c++11/
#9 0x00007f2da1979a9d in start_thread () at /usr/lib/
#10 0x00007f2da18a9b23 in clone () at /usr/lib/

I am not sure I can reproduce it, but it happened when I tried to place a symbol I just picked from the symbol chooser. It felt sort of slow to place it, meaning the that opaque.

Application: kicad
Version: (5.1.0-161-gd928aa978), debug build
    wxWidgets 3.0.4
    libcurl/7.64.1 OpenSSL/1.1.1b zlib/1.2.11 libidn2/2.1.1 libpsl/0.20.2 (+libidn2/2.1.1) libssh2/1.8.1 nghttp2/1.36.0
Platform: Linux 5.0.5-arch1-1-ARCH x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
    Boost: 1.69.0
    Curl: 7.64.1
    Compiler: GCC 8.2.1 with C++ ABI 1013

Build settings:

tags: added: eeschema
Nick Østergaard (nickoe) wrote :
Download full text (4.4 KiB)

I got another crash, with another backtrace but triggered by similar actions. In this case I was placing a hierarchical pin in the symbol for a subsheet.

Version: (5.1.0-161-gd928aa978), debug build

(gdb) bt
#0 0x00007f53fbb8b9f2 in std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::length() const (this=0x6500000065)
    at /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:936
#1 0x00007f53fbb8b9f2 in std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_M_assign(std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&)
    (this=0x7ffc651b9d88, __str=<error reading variable: Cannot access memory at address 0x650000006d>) at /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:259
#2 0x00007f53fcbf62e1 in wxStringTokenizer::Reinit(wxString const&) () at /usr/lib/
#3 0x00007f53fcbf6891 in wxStringTokenizer::SetString(wxString const&, wxString const&, wxStringTokenizerMode) () at /usr/lib/
#4 0x00007f53ed55c3c2 in SCH_COMPONENT::GetRef(SCH_SHEET_PATH const*) (this=0x55c963762ef0, sheet=0x7ffc651ba090) at /home/nickoe/kicad-source-mirror/eeschema/sch_component.cpp:593
#5 0x00007f53ed5ca6ec in SCH_PIN::GetDefaultNetName(SCH_SHEET_PATH) (this=0x55c963768060, aPath=...) at /home/nickoe/kicad-source-mirror/eeschema/sch_pin.cpp:75
#6 0x00007f53ed49fdda in CONNECTION_GRAPH::updateItemConnectivity(SCH_SHEET_PATH, std::vector<SCH_ITEM*, std::allocator<SCH_ITEM*> >) (this=0x55c9532e7a20, aSheet=..., aItemList=std::vector of length 205, capacity 205 = {...})
    at /home/nickoe/kicad-source-mirror/eeschema/connection_graph.cpp:376
#7 0x00007f53ed49f559 in CONNECTION_GRAPH::Recalculate(SCH_SHEET_LIST, bool) (this=0x55c9532e7a20, aSheetList=..., aUnconditional=true) at /home/nickoe/kicad-source-mirror/eeschema/connection_graph.cpp:316
#8 0x00007f53ed5fe93f in SCH_EDIT_FRAME::RecalculateConnections() (this=0x55c955b45110) at /home/nickoe/kicad-source-mirror/eeschema/sch_edit_frame.cpp:1537
#9 0x00007f53ed5fdd85 in SCH_EDIT_FRAME::addCurrentItemToScreen() (this=0x55c955b45110) at /home/nickoe/kicad-source-mirror/eeschema/sch_edit_frame.cpp:1462
#10 0x00007f53ed523973 in SCH_EDIT_FRAME::OnLeftClick(wxDC*, wxPoint const&) (this=0x55c955b45110, aDC=0x0, aPosition=...) at /home/nickoe/kicad-source-mirror/eeschema/onleftclick.cpp:90
#11 0x00007f53ed53c100 in SCH_DRAW_PANEL::OnMouseEvent(wxMouseEvent&) (this=0x55c9559e3a70, event=...) at /home/nickoe/kicad-source-mirror/eeschema/sch_draw_panel.cpp:363
#12 0x00007f53fcc8a89e in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () at /usr/lib/
#13 0x00007f53fcc8ac1b in wxEvtHandler::SearchDynamicEventTable(wxEvent&) () at /usr/lib/
#14 0x00007f53fcc8acb1 in wxEvtHandler::TryHereOnly(wxEvent&) () at /usr/lib/
#15 0x00007f53fcc8ad64 in wxEvtHandler::ProcessEventLocally(wxEvent&) () at /usr/lib/
#16 0x00007f53fcc8ae02 in wxEvtHandler::ProcessEvent(wxEvent&) () at /...


Jon Evans (craftyjon) on 2019-04-08
Changed in kicad:
assignee: nobody → Jon Evans (craftyjon)
Jon Evans (craftyjon) wrote :

Ahh, another wxString threading crash, it looks like. At least the first one.
The second one might be also, but the backtrace is from a non-threaded area.

Jon Evans (craftyjon) wrote :

Are you still getting these Nick? If so, are the backtraces still the same?

Jeff Young (jeyjey) wrote :

@Jon, I looked into the wchar_t vs char compiler flag, and I really don't think it's going to cause a lot of bugs like @Wayne worries. The only downside appears to be more storage for strings, but it's not like we're a word-processor with tons of text (and besides, even then text is tiny next to bitmaps).

Anyway, I think it's worth trying at least locally. If it works we could rip out many of the mutex hacks....

Jon Evans (craftyjon) wrote :

Sounds good Jeff!

Is lp:1825170 related with? (last report mine I release that the crash just happens when I search by alphabet characters and not just number, sometimes the crash is after place or give some zoom.

Jon Evans (craftyjon) wrote :

This does not look like the same bug.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers