Eeschema segfault when deactivating new symbol tool (MacOS)

Bug #1839653 reported by Christoph Nieß
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
KiCad
Fix Committed
Critical
Jeff Young

Bug Description

I can't reliably reproduce this, but have had a significant number of crashes that I've noticed all happened when I deactivated the part selection tool by pressing escape after having placed a part.

Version Info:
Application: KiCad
Version: (5.1.0-1458-gf057bfc7c), debug build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.54.0 LibreSSL/2.6.5 zlib/1.2.11 nghttp2/1.24.1
Platform: Mac OS X (Darwin 18.7.0 x86_64), 64 bit, Little endian, wxMac
Build Info:
    wxWidgets: 3.0.4 (wchar_t,STL containers,compatible with 2.8)
    Boost: 1.69.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.54.0
    Compiler: Clang 9.0.0 with C++ ABI 1002

Build settings:
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    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

Tags: eeschema
Revision history for this message
Christoph Nieß (toffi-mixedstuff) wrote :
Revision history for this message
Jeff Young (jeyjey) wrote :

This dies trying to log an error parsing an accelerator while updating the menu. It's either:

wxLogDebug(wxT("Unknown accel modifier: '%s'"), current.c_str());

or:

wxLogDebug(wxT("No accel key found, accel string ignored."));

or:

wxLogDebug(wxT("Unrecognized accel key '%s', accel string ignored."), current.c_str());

The actual SIGSEGV is in the logging code, and may be related to the crash-on-quit we've seen a couple of times trying to delete a NULL logger.

Revision history for this message
Jeff Young (jeyjey) wrote :

During a normal run I get some debug logs:

21:10:51: Debug: Unrecognized accel key 'backspace', accel string ignored.

so that's probably the trigger (although not specifically the bug as it should be able to log that).

Revision history for this message
Jeff Young (jeyjey) wrote :

It's Leave sheet's Alt+Back that seems to trigger it. (Which is odd, since the accelerator does work.)

Revision history for this message
Ian McInerney (imcinerney) wrote :

@Jeff, that debug message is coming from wxWidget's internal processing of the accelerator keys and is because it is unable to create a wxAcceleratorEntry for the key named backspace. I also see that on Linux all the time, but I haven't seen the crashes mentioned in all the reports.

PS: that debug message should go away in the next wxWidgets 3.1.x release, once they merge the fix.

Revision history for this message
Jeff Young (jeyjey) wrote :

wxWidgets bug: http://trac.wxwidgets.org/ticket/11324

Logged 10 years ago. Last modified 10 years ago. Splendid.

Revision history for this message
Ian McInerney (imcinerney) wrote :

@Jeff, it should be fixed in this commit sequence to wx: https://github.com/wxWidgets/wxWidgets/pull/1463. They just haven't merged it yet.

Revision history for this message
Jeff Young (jeyjey) wrote :

Menu issue fixed in f90e5e4a56060fba0ec11769eef7ed60aa9af766 in our local wxWidgets branch.

None of this explains the log issue, but at least the accelerator problem won't trigger it now (and the accelerator now appears in the view menu).

Revision history for this message
Jeff Young (jeyjey) wrote :

@Ian, thanks for that. I didn't see your comments till I had already patched our local version we use for Mac builds, but my fix is pretty similar.

I have a hazy memory of someone talking about updating our local version to 3.1.x. Was that you or Michael or someone else? Did it ever get anywhere?

Jeff Young (jeyjey)
Changed in kicad:
importance: Undecided → Critical
assignee: nobody → Jeff Young (jeyjey)
milestone: none → 6.0.0-rc1
status: New → Fix Committed
Revision history for this message
Ian McInerney (imcinerney) wrote :

@Jeff, I don't have an OSX box so it was probably Michael you spoke to. I don't know how much work it would take to switch over the build script to use the 3.1 branch, you would probably need to pull Adam into that discussion. In my opinion, it wouldn't be bad to give it a try just to see how it behaves on Mac. Also, any bugs we do find in 3.1 we could file upstream and hopefully have them fixed for 3.2.

I have been thinking of making a local build on my machine that uses 3.1 on GTK, just to see if some of the glitches I see occasionally still exist and if there might be any problems to push to upstream.

Revision history for this message
Ian McInerney (imcinerney) wrote :

@Jeff, I just had a dive into the wxWidgets code and am curious if you tried something. It looks like we should be able to set the static variable wxApp::s_macPreferencesMenuItemId to wxID_NONE and it won't move the item. Did you give that a go?

I think all we would need to do is a conditional compilation for mac of this code somewhere in the beginning of the program initialization:
wxApp::s_macPreferencesMenuItemId = wxID_NONE;

I have added this call inside the conditional compilation for Mac in PGM_BASE::InitPgm in the attached patch. Can you back out the patch to local wxWidgets and then apply this one to the KiCad source to see if this fixes the issue? If it does, this would be preferable since it doesn't rely on a patched version of wxWidgets, and it shouldn't break the other platforms.

Revision history for this message
Jeff Young (jeyjey) wrote :

@Ian, that would be another option, but it goes against platform conventions.

Also, we always build the Mac version against our own wxWidgets. There are 29(!) other patches in it.

Revision history for this message
Ian McInerney (imcinerney) wrote :

Ah, so it isn't the movement part that is the problem, it is the fact that it is removing the old icon. I thought it was the movement to the App menu we wanted to avoid.

tags: added: eeschema
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.