Pcbnew: all submenus trigger assertion

[Wayne Stambaugh]

Attempting to open any submenu in Pcbnew triggers the assertion shown in the attached screen shot. Dismissing the dialog with the "Show this dialog next time" unchecked does not allow the submenu to function properly. They close immediately which makes them impossible to select. This may only affect GTK builds. I have also attached the stack trace from the wxWidgets assertion dialog. This does not happen in Eeschema.

Application: Pcbnew
Version: (5.1.0-1460-g726bceecf), debug build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.65.1 OpenSSL/1.1.1c zlib/1.2.11 libidn2/2.2.0 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.37.0 librtmp/2.3
Platform: Linux 4.19.0-5-amd64 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.67.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.65.1
    Compiler: Clang 7.0.1 with C++ ABI 1002

Build settings:
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
    KICAD_STDLIB_DEBUG=OFF
    KICAD_STDLIB_LIGHT_DEBUG=OFF
    KICAD_SANITIZE=OFF

ASSERT INFO:
../src/gtk/menu.cpp(84): assert "win" failed in DoCommonMenuCallbackCode(): event for a menu without associated window?

BACKTRACE:
[1] g_closure_invoke
[2] g_signal_emit_valist
[3] g_signal_emit
[4] gtk_menu_shell_deselect
[5] gtk_menu_popdown
[6] g_closure_invoke
[7] g_signal_emit_valist
[8] g_signal_emit_by_name
[9] g_cclosure_marshal_VOID__OBJECTv
[10] g_signal_emit_valist
[11] g_signal_emit
[12] gtk_container_remove
[13] g_object_run_dispose
[14] wxMenu::~wxMenu()
[15] wxMenuBarBase::~wxMenuBarBase()
[16] wxMenuBar::~wxMenuBar()
[17] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[18] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[19] wxEvtHandler::TryHereOnly(wxEvent&)
[20] wxEvtHandler::DoTryChain(wxEvent&)
[21] wxEvtHandler::ProcessEvent(wxEvent&)
[22] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[23] wxWindowBase::SendIdleEvents(wxIdleEvent&)
[24] wxFrame::SendIdleEvents(wxIdleEvent&)
[25] wxAppBase::ProcessIdle()
[26] wxApp::DoIdle()
[27] g_main_context_dispatch
[28] g_main_loop_run
[29] gtk_main
[30] wxGUIEventLoop::DoRun()
[31] wxEventLoopBase::Run()
[32] wxAppConsoleBase::MainLoop()
[33] APP_KICAD::OnRun() /home/wayne/src/kicad-trunk/kicad/kicad.cpp:261
[34] wxEntry(int&, wchar_t**)
[35] main /home/wayne/src/kicad-trunk/kicad/kicad.cpp:292
[36] __libc_start_main
[37] _start

[Jeff Young (jeyjey)]

@Wayne, could you merge out and try this again?

That's pretty poor form for GTK to be processing idle events when a menu is pulled down, but if that's what's happening the code I checked in *may* fix the assert.

[Wayne Stambaugh (stambaughw)]

@Jeff, idle time is when wxWidgets updates UI events. Update UI events are called just before a menu is expanded. This is documented here https://docs.wxwidgets.org/3.0/classwx_update_u_i_event.html. I suspect it is the event timing differences between platforms that is the issue. That being said your fix solved the issue.