eeschema segfault on undo
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
KiCad |
Fix Released
|
Critical
|
Unassigned |
Bug Description
(bzr-5528)
hmm... anybody feel like doing some pointer tracing? I started getting into it but then realized I was getting too deep into things to have time to do this right now...
Just got a segfault in eeschema on undo. Poking around in the core dump, it looks like there was an invalid pointer in an ITEM_PICKER:
Here's the last *valid* line:
/home/cmp/
item->Move( ... );
The next line, bizarrely, is dialog_
The reason for this is clear, going to the last valid frame and inspecting "item":
(gdb) p item
$16 = (SCH_ITEM *) 0x1c1acc0
(gdb) p *item
$17 = {<EDA_ITEM> = {<KIGFX::VIEW_ITEM> = {_vptr.VIEW_ITEM = 0x7f02537f0310 <vtable for dialog_about+16>, m_view = 0x0, m_flags = 1, m_requiredUpdate = 255, m_groups = 0x0, m_groupsSize = 0,
m_layers = std::bitset}, m_StructType = SCH_LINE_T, m_Status = 0, Pnext = 0x1c1ad90, Pback = 0x1c1ac00, m_List = 0x7f02537f6700 <s_oldWires>, m_Parent = 0x0, m_TimeStamp = 1427099594,
m_forceVisible = false, m_Flags = 0, m_Image = 0x0}, m_Layer = LAYER_FIRST, m_connections = std::vector of length 0, capacity 0, m_storedPos = {x = 0, y = 0}}
-----
<vtable for dialog_about+16>
So, either the data has been corrupted, or the pointer was invalid. Likely, it's going to take someone looking through every ITEM_PICKER:
-----
I won't delete the core dump, so let me know if there's any more information I can drag out of it.
-----
Full backtrace:
#0 0x00007f0262c1fe94 in free () from /usr/lib/libc.so.6
#1 0x00007f025315548b in wxString:
#2 0x00007f025315336d in wxString::~wxString (this=0x1c1b1b0, __in_chrg=
#3 0x00007f02533dfa13 in AboutAppInfo:
#4 0x00007f02533e071d in dialog_
#5 0x00007f02532d1da6 in SCH_EDIT_
#6 0x00007f02532d2156 in SCH_EDIT_
#7 0x00007f0264266b5e in wxAppConsoleBas
#8 0x00007f0264403508 in wxEvtHandler:
#9 0x00007f026440360b in wxEventHashTabl
#10 0x00007f02644039b8 in wxEvtHandler:
#11 0x00007f025332d4ef in EDA_BASE_
#12 0x00007f02644037c3 in wxEvtHandler:
#13 0x00007f0264403aa5 in wxEvtHandler:
#14 0x00007f0253230f26 in SCH_EDIT_
#15 0x00007f0253190c46 in SCH_EDIT_
#16 0x00007f0253398b54 in EDA_DRAW_
#17 0x00007f0264266b5e in wxAppConsoleBas
#18 0x00007f0264403508 in wxEvtHandler:
#19 0x00007f026440360b in wxEventHashTabl
#20 0x00007f02644039b8 in wxEvtHandler:
#21 0x00007f0264403a43 in wxEvtHandler:
#22 0x00007f0264403aa5 in wxEvtHandler:
#23 0x00007f0264e315cb in wxScrollHelperE
#24 0x00007f0264403817 in wxEvtHandler:
#25 0x00007f0264bcde3a in ?? () from /usr/lib/
#26 0x00007f026269490f in ?? () from /usr/lib/
#27 0x00007f026206c175 in g_closure_invoke () from /usr/lib/
#28 0x00007f026207da5c in ?? () from /usr/lib/
#29 0x00007f0262086205 in g_signal_
#30 0x00007f026208695f in g_signal_emit () from /usr/lib/
#31 0x00007f02627abb9c in ?? () from /usr/lib/
#32 0x00007f02627bf6ab in gtk_window_
#33 0x00007f0264bbb3b8 in ?? () from /usr/lib/
#34 0x00007f026269490f in ?? () from /usr/lib/
#35 0x00007f026206c175 in g_closure_invoke () from /usr/lib/
#36 0x00007f026207da5c in ?? () from /usr/lib/
#37 0x00007f0262086205 in g_signal_
#38 0x00007f026208695f in g_signal_emit () from /usr/lib/
#39 0x00007f02627abb9c in ?? () from /usr/lib/
#40 0x00007f026269312f in gtk_propagate_event () from /usr/lib/
#41 0x00007f02626934eb in gtk_main_do_event () from /usr/lib/
#42 0x00007f02623082cc in ?? () from /usr/lib/
#43 0x00007f026134771d in g_main_
#44 0x00007f0261347a08 in ?? () from /usr/lib/
#45 0x00007f0261347d32 in g_main_loop_run () from /usr/lib/
#46 0x00007f0262692467 in gtk_main () from /usr/lib/
#47 0x00007f0264b9d1d5 in wxGUIEventLoop:
#48 0x00007f02642acd50 in wxEventLoopBase
#49 0x00007f0264268f06 in wxAppConsoleBas
#50 0x000000000043ee7c in APP_KICAD::OnRun (this=0xe75bf0) at /home/cmp/
#51 0x00007f026430481d in wxEntry(int&, wchar_t**) () from /usr/lib/
#52 0x000000000043d226 in main (argc=1, argv=0x7fff5489
tags: | added: eeschema undo |
Changed in kicad: | |
status: | Fix Committed → Fix Released |
For what it's worth, it just happened to me again on the same schematic, which is just demos/pic_ programmer. Still not able to properly reproduce it, but as I've never seen this before and now one schematic has done it twice, maybe that one's more prone to it for some reason. Might be a starting point.