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

Bug #1778408 reported by Reece Pollack on 2018-06-24
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Seth Hillbrand

Bug Description

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.

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

[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
    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:

Reece Pollack (reece-pollack) wrote :
Seth Hillbrand (sethh) wrote :

Hi Reece-

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

Changed in kicad:
status: New → Incomplete
Reece Pollack (reece-pollack) wrote :

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) wrote :

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

Reece Pollack (reece-pollack) wrote :

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) wrote :

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

Changed in kicad:
importance: Undecided → Low
milestone: none → 5.0.0-rc3
status: Incomplete → Triaged
Reece Pollack (reece-pollack) wrote :


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) wrote :

Fixed in revision 4af699e919d7d83272bf550b34c035d582d5be30

Changed in kicad:
status: Triaged → Fix Committed
assignee: nobody → Seth Hillbrand (sethh)
Seth Hillbrand (sethh) wrote :

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

Changed in kicad:
milestone: 5.0.0-rc3 → 5.1.0
Changed in kicad:
status: Fix Committed → Fix Released
Jeff Young (jeyjey) wrote :

Setting back to "Confirmed" for 5.1 work.

Changed in kicad:
status: Fix Released → Confirmed
Jeff Young (jeyjey) wrote :

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

Seth Hillbrand (sethh) wrote :

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) wrote :

Fixed in revision 594d5c3e34f177836aaa8d345db6aed023031dab

Changed in kicad:
status: Confirmed → Fix Committed
Changed in kicad:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers