assert "global_actions_cnt <= 1" failed in UpdateHotKeys().

[Reece Pollack]

I see 6 of these when I open my board file.

I thought I saw discussion on this in the dev list, but my search came up empty. I'm including the files in my ~/.config/kicad directory, but since an assert is supposed to indicate a problem in the code this shouldn't happen regardless of their content.

ASSERT INFO:
/home/reece/MyProjects/KiCad/kicad/common/tool/action_manager.cpp(222): assert "global_actions_cnt <= 1" failed in UpdateHotKeys().

BACKTRACE:
[1] KIWAY::Player(FRAME_T, bool, wxTopLevelWindow*) /home/reece/MyProjects/KiCad/kicad/common/kiway.cpp:335
[2] KICAD_MANAGER_FRAME::RunPcbNew(wxString const&) /home/reece/MyProjects/KiCad/kicad/kicad/mainframe.cpp:385
[3] KICAD_MANAGER_FRAME::OnRunPcbNew(wxCommandEvent&) /home/reece/MyProjects/KiCad/kicad/kicad/mainframe.cpp:419
[4] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[5] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[6] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[7] wxEvtHandler::TryHereOnly(wxEvent&)
[8] EDA_BASE_FRAME::ProcessEvent(wxEvent&) /home/reece/MyProjects/KiCad/kicad/common/eda_base_frame.cpp:194
[9] wxEvtHandler::DoTryChain(wxEvent&)
[10] wxEvtHandler::ProcessEvent(wxEvent&)
[11] wxWindowBase::TryAfter(wxEvent&)
[12] wxWindowBase::TryAfter(wxEvent&)
[13] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[14] g_signal_emit_valist
[15] g_signal_emit
[16] g_closure_invoke
[17] g_signal_emit_valist
[18] g_signal_emit
[19] g_closure_invoke
[20] g_signal_emit_valist
[21] g_signal_emit
[22] gtk_propagate_event
[23] gtk_main_do_event
[24] g_main_context_dispatch
[25] g_main_loop_run
[26] gtk_main
[27] wxGUIEventLoop::DoRun()
[28] wxEventLoopBase::Run()
[29] wxAppConsoleBase::MainLoop()
[30] APP_KICAD::OnRun() /home/reece/MyProjects/KiCad/kicad/kicad/kicad.cpp:256
[31] wxEntry(int&, wchar_t**)
[32] main /home/reece/MyProjects/KiCad/kicad/kicad/kicad.cpp:287
[33] __libc_start_main
[34] _start

KiCad built from sources derived from this Git commit:
    f785d27 Eeschema, label editor dialog: fix a very minor cosmetic issue when resizing the dialog.

Application: kicad
Version: (5.0.0-rc2-202-g4d2b4d3), debug build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.11 libidn/1.32 librtmp/2.3
Platform: Linux 4.13.0-41-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
    OpenCASCADE Community Edition: 6.8.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_USE_OCC=OFF
    KICAD_SPICE=ON

[Seth Hillbrand (sethh)]

Hi Reece-

If you choose Edit Hotkeys -> Reset to Defaults this assert should go away.

[Reece Pollack (reece-pollack)]

Of course, NOW I find the discussion. It relates to Bug #1776785 which is reported as "Fix committed". Yet the assertion is still asserted.

[Maciej Suminski (orsonmmz)]

Reece, do you mean that "Reset to Defaults" does not help?

[Reece Pollack (reece-pollack)]

Yes, I haven't tried to reset the hotkeys to their defaults. This is irrelevant to the problem.

An assert is generally used to identify "this should never happen" conditions in software. This condition is one where the user should be notified with a dialog box indicating that there are conflicting hotkey definitions and suggesting a solution, rather than an assert.

[Seth Hillbrand (sethh)]

Hi Reece-

This is a valid point. We can't do a dialog box for now as we are at string freeze but we can either reset the hotkeys to default or clear the conflicting hotkeys

[Reece Pollack (reece-pollack)]

Seth,

I have confidence that there will be another release after 5.0.0; we can fix it properly by notifying the user then.

I don't have an opinion on how this should be addressed in the 5.0.0 release. Given how close we are to the release I would suggest taking whatever approach has the fewest unexpected results for the user.

[KiCad Janitor (kicad-janitor)]

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

[Seth Hillbrand (sethh)]

OK, I cleared the step that causes this to show an issue when upgrading from v4.

We'll revisit the clean notification during v5.1

[Jeff Young (jeyjey)]

Setting back to "Confirmed" for 5.1 work.

[Jeff Young (jeyjey)]

@Seth, do you remember what you had in mind for this, or should we push it to 6.0?

[Seth Hillbrand (sethh)]

I was thinking of a two-step process:

1) If there is a v5 hotkey file, read that and return.

2) Else, if there is a v4 hotkey file, prompt the user to import the old hotkey file and immediately save it in the v5 file.

Step 1 already exists. Step 2 just needs a warning dialog and a bit more error checking when reading the file (to avoid the duplicates)

[KiCad Janitor (kicad-janitor)]

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