Eeschema: FP selection: List with too many symbols

[Michael Geselbracht]

When a footprint is assigned to a symbol using the 'F' key and the library browser, a previously selected library is pre-selected when the browser opens. That's good but the list of symbols for this lib contains many entries that do not belong to it. It also seems to take a lot of time to create this list.

Steps to reproduce:
0. Start Kicad, open Eeschema and load a schematic.
1. Move cursor above a symbol with an assigned FP, press 'F' and press "Select".
2. In the lib browser, select a small lib (Battery) and cancel/close both dialogs.
3. Add a resistor to the schematic, press 'F' and press "Select"
  -> lib browser opens with "Battery" selected. There are many more symbols listed than before.

git bisect found commit f4ce8766e38 for this issue BUT only if Eeschema is opened from the Kicad control app. If Eeschema is run standalone it crashes at step 3. That also happens with older commits.

Application: kicad
Version: (5.0.0-rc2-dev-361-g747e14f9e), release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.8 libidn/1.32 librtmp/2.3
Platform: Linux 4.4.0-116-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.58.0
    Curl: 7.47.0
    Compiler: GCC 5.4.0 with C++ ABI 1009

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=OFF
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=ON

[Jeff Young (jeyjey)]

@Seth, were you able to reproduce this?

@Michael, are you using GitHub libraries or anything unusual?

[Jeff Young (jeyjey)]

(I'll look into the crash first, as that does reproduce for me.)

[Seth Hillbrand (sethh)]

Yes, I reproduced both issues using an existing schematic under linux. Stock libraries.

[Jeff Young (jeyjey)]

The crash happens doing the cross-probe to pcbnew. It's inside:

   sock_client->WaitOnConnect( 0, 100 );

and we've gotten some sort of socket event (I can't tell what) and wxWidgets is trying to execute an OnStateChange() callback, only m_handler appears to be NULL.

Call stack:

wxSocketBase::OnRequest(wxSocketNotify) socket.cpp:1728
wxSocketImpl::NotifyOnStateChange(wxSocketNotify) socket.cpp:583
wxSocketImplUnix::OnStateChange(wxSocketNotify) sockunix.cpp:140
wxSocketImplUnix::OnReadWaiting() sockunix.cpp:200
(anonymous namespace)::wxSocketImplMac::SocketCallback(__CFSocket*, unsigned long, __CFData const*, void const*, void*) sockosx.cpp:151
__CFSocketPerformV0 0x00007fff435105a8
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 0x00007fff434f1721
__CFRunLoopDoSource0 0x00007fff435ab0ac
__CFRunLoopDoSources0 0x00007fff434d42bc
__CFRunLoopRun 0x00007fff434d36dd
CFRunLoopRunSpecific 0x00007fff434d2f43
RunCurrentEventLoopInMode 0x00007fff427eae26
ReceiveNextEventCommon 0x00007fff427eaa9f
_BlockUntilNextEventMatchingListInModeWithFilter 0x00007fff427ea914
_DPSNextEvent 0x00007fff40ab5f5f
-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] 0x00007fff4124bb4c
wxGUIEventLoop::DoDispatchTimeout(unsigned long) evtloop.mm:239
wxCFEventLoop::DispatchTimeout(unsigned long) evtloop_cf.cpp:259
wxSocketBase::DoWait(long, int) socket.cpp:1484
wxSocketBase::DoWait(long, long, int) socket.cpp:1414
wxSocketClient::WaitOnConnect(long, long) socket.cpp:2057
SendCommand(int, char const*) eda_dde.cpp:197
SCH_EDIT_FRAME::SendMessageToPCBNEW(EDA_ITEM*, SCH_COMPONENT*) cross-probing.cpp:194
SCH_EDIT_FRAME::LocateAndShowItem(wxPoint const&, KICAD_T const*, int, bool*) controle.cpp:99
SCH_EDIT_FRAME::OnEditItem(wxCommandEvent&) schedit.cpp:1010
wxAppConsoleBase::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const appbase.cpp:611
wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const appbase.cpp:623
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) event.cpp:1395
wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) event.cpp:1001
wxEvtHandler::TryHereOnly(wxEvent&) event.cpp:1592
wxEvtHandler::TryBeforeAndHere(wxEvent&) event.h:3680
wxEvtHandler::ProcessEvent(wxEvent&) event.cpp:1494
EDA_BASE_FRAME::ProcessEvent(wxEvent&) eda_base_frame.cpp:202
wxEvtHandler::DoTryChain(wxEvent&) event.cpp:1557
wxEvtHandler::ProcessEventLocally(wxEvent&) event.cpp:1525
wxEvtHandler::ProcessEvent(wxEvent&) event.cpp:1498
SCH_EDIT_FRAME::OnHotKey(wxDC*, int, wxPoint const&, EDA_ITEM*) hotkeys.cpp:634
SCH_EDIT_FRAME::GeneralControl(wxDC*, wxPoint const&, unsigned int) controle.cpp:265
EDA_DRAW_PANEL::OnKeyEvent(wxKeyEvent&) draw_panel.cpp:1491
wxAppConsoleBase::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const appbase.cpp:611
wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const appbase.cpp:623
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) event.cpp:1395
wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) event.cpp:1001
wxEvtHandler::TryHereOnly(wx...

[Jeff Young (jeyjey)]

This bug is dependent on the footprint browser being shown before the cross-probe is made. IIRC, when creating the FP Viewer canvas we open a PCBNew frame in the background to copy some settings out of it. I wonder if this is somehow the culprit?

[Jeff Young (jeyjey)]

I figured out how to reproduce the other part: you must have "Footprint previews in symbol chooser (experimental)" turned on.

[Jeff Young (jeyjey)]

I've got a fix for the too-many-batteries part.

I'll poke at the cross-probing issue tomorrow....

[Michael Geselbracht (mgeselbracht)]

It's probably not relevant anymore but I am using the 5.0.0-rc1 libs from Github.
The FP preview option is enabled.

[Jeff Young (jeyjey)]

The cross-probing doesn't crash on the sending side, but rather on the receiving side (m_handler is the temporary pcbnew frame, and has been deleted).

The list of accepted sockets needs to be stored in EDA_BASE_FRAME so that they can be shutdown in its d'tor.

[KiCad Janitor (kicad-janitor)]

Fixed in revision df43f071e1e750fa839ccf177fd57f1fe642953c
https://git.launchpad.net/kicad/patch/?id=df43f071e1e750fa839ccf177fd57f1fe642953c