NULL component reference assert after failed or skipped remapping

Bug #1794570 reported by Matthias Urlichs
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
KiCad
Triaged
High
Unassigned

Bug Description

Version: current 5.0-dev branch, 5.0.0 release

Opening eeschema(*) and selecting "Tools → Edit Symbol Library References…" causes an immediate assertion failure.

(*) I was trying to open an old file which requires me to re-map symbols, which failed. The error also occurs when skipping the re-mapping.

/home/smurf/src/kicad/eeschema/component_references_lister.cpp(721): assert "aComponent != __null && aLibPart != __null" failed in SCH_REFERENCE().

BACKTRACE:
[1] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[2] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[3] wxEvtHandler::TryHereOnly(wxEvent&)
[4] wxEvtHandler::DoTryChain(wxEvent&)
[5] wxEvtHandler::ProcessEvent(wxEvent&)
[6] wxWindowBase::TryAfter(wxEvent&)
[7] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[8] wxMenuBase::SendEvent(int, int)
[9] g_closure_invoke
[10] g_signal_emit_valist
[11] g_signal_emit
[12] gtk_widget_activate
[13] gtk_menu_shell_activate_item
[14] g_closure_invoke
[15] g_signal_emit_valist
[16] g_signal_emit
[17] gtk_propagate_event
[18] gtk_main_do_event
[19] g_main_context_dispatch
[20] g_main_loop_run
[21] gtk_main
[22] wxGUIEventLoop::DoRun()
[23] wxEventLoopBase::Run()
[24] wxAppConsoleBase::MainLoop()
[25] wxEntry(int&, wchar_t**)
[26] __libc_start_main
[27] _start

Revision history for this message
Maciej Suminski (orsonmmz) wrote :

Please post complete version information from menu Help->About KiCad->Copy Version.

Revision history for this message
Matthias Urlichs (smurf) wrote :

Application: kicad
Version: (5.0.1-dev-161-gb2b703363-dirty)+git1-1f19903-1, release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.60.0 OpenSSL/1.1.0h zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.32.0 librtmp/2.3
Platform: Linux 4.17.0-1-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.62.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.60.0
    Compiler: GCC 7.3.0 with C++ ABI 1011

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

Jeff Young (jeyjey)
summary: - eeschema: Failed assertion selecting "Tools→Edit Symbol Library
- References…"
+ NULL component reference assert after failed or skipped remapping
Jeff Young (jeyjey)
Changed in kicad:
importance: Undecided → High
Revision history for this message
Seth Hillbrand (sethh) wrote :

@Jeff- Can you recreate this? I'm not having any luck.

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

@Seth, no, I was never able to reproduce it. (And I can't now either.)

Revision history for this message
Seth Hillbrand (sethh) wrote :

@Mattias- Are you able to reliably recreate this issue with the same project?

If so, can you post the project or e-mail it separately?

Changed in kicad:
status: New → Incomplete
Revision history for this message
Bernhard (schlimmchen) wrote :

I am fiddling with my projects from May of 2018. These were created with kicad 5.0.0 RC2 on debian, using the deprecated libraries for kicad 4.
My goal is to prepare the projects such that they work independently of the libraries installed on the system. Then I plan to transition to
kicad 5.0.2 "release" in debian stretch-backports. While doing all this, I stumbled over this issue and a way to reproduce it.

Open the schematic from the provided demo project using kicad 5.0.2. Even if you have all symbols provided by kicad from
https://github.com/KiCad/kicad-symbols enabled, you should be prompted to rescue two symbols: "Mechanical:Mounting_Hole_PAD"
and "Relay:FINDER-40.52". Choose NOT to rescue at least one symbol.

In eeschema, choose Tools -> Edit Symbol Library References...

You'll see an assertion dialog. When clicking "Continue", you'll see one for each symbol instance without a valid library
reference.

ASSERT INFO:
/build/kicad-UO6Edp/kicad-5.0.2+dfsg1/eeschema/component_references_lister.cpp(721): assert "aComponent != __null && aLibPart != __null" failed in SCH_REFERENCE().

BACKTRACE:
[1] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[2] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[3] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[4] wxEvtHandler::TryHereOnly(wxEvent&)
[5] wxEvtHandler::DoTryChain(wxEvent&)
[6] wxEvtHandler::ProcessEvent(wxEvent&)
[7] wxWindowBase::TryAfter(wxEvent&)
[8] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[9] wxMenuBase::SendEvent(int, int)
[10] g_closure_invoke
[11] g_signal_emit_valist
[12] g_signal_emit
[13] gtk_widget_activate
[14] gtk_menu_shell_activate_item
[15] g_closure_invoke
[16] g_signal_emit_valist
[17] g_signal_emit
[18] gtk_propagate_event
[19] gtk_main_do_event
[20] g_main_context_dispatch
[21] g_main_loop_run
[22] gtk_main
[23] wxGUIEventLoop::DoRun()
[24] wxEventLoopBase::Run()
[25] wxAppConsoleBase::MainLoop()
[26] wxEntry(int&, wchar_t**)
[27] __libc_start_main
[28] _start

I assume this assertion makes sense, in a way, but in this particular circumstance, it seems that this assertion is expected.

Changed in kicad:
status: Incomplete → Confirmed
Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

Isn't this a duplicate of lp:1809622?

Revision history for this message
Seth Hillbrand (sethh) wrote :

@Wayne-

That one is MSW build options. This one looks like Debian. Maybe Carsten can look at how these were enabled.

Revision history for this message
Seth Hillbrand (sethh) wrote :

Just tested the attached project in Debian buster with debug asserts on and do not see any. I'll set the bug to fix committed unless someone can find configuration that still asserts in master.

Application: kicad
Version: (6.0.0-rc1-dev-1537-gf57746eb74), debug build
Libraries:
    wxWidgets 3.0.4
Platform: Linux 4.18.0-3-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
    Compiler: GCC 8.2.0 with C++ ABI 1013

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

Changed in kicad:
status: Confirmed → Fix Committed
Revision history for this message
tijuca (c-schoenert) wrote :

Taken the build path snippet from the Assert message line I can puzzle out that this is from the build of kicad 5.0.2+dfsg1-1~bpo9+1 on amd64. But it would be easier if the reporter can provide all of these information, this saves times and also decreases assumptions. ;)

https://buildd.debian.org/status/fetch.php?pkg=kicad&arch=amd64&ver=5.0.2%2Bdfsg1-1%7Ebpo9%2B1&stamp=1545170655&raw=0

But that is not the interesting part.

I tried to follow the steps for reproducing the behaviour about the assert messages and unfortunately I can reproduce this also on Debian testing with the current version of KiCad 5.0.2+dfsg1-1. I have no additional software like plugins or extra library parts installed, simple plain kicad with the schematic and footprint libraries from the archive.

But I can't reproduce this with the version from experimental (which is GTK+3 based).

Regards
Carsten

Revision history for this message
jean-pierre charras (jp-charras) wrote :

I fixed it both in master and stable 5.03 branches.

This is a overzealous wxASSERT, and should not be visible (obviously) in release mode, only in debug build and only in 5.02.

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

I think there is a problem with our cmake files. I am in the process of running a git bisect on the 5.0 branch. The assert does not fire on 5.0.0 so it appears that we broke something in our cmake configuration. Even if the assert was overzealous, it still should not have fired on a release build so the current fix does not resolve the under lying problem. It take a while to complete the bisect as building one windows is slow.

Revision history for this message
Matthias Urlichs (smurf) wrote :

@tijuca: "it would be easier if the reporter can provide all of these information, "

Umm … bug fixing tends to be easier when you read the bug report? ;-)

I posted that, third message in this bug.

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

I was wrong. It was not a cmake change that caused the issue. Commit 57800b93 is the problem. It is setting the assert handler on non-debug builds on windows. This is why we are not seeing it on other platforms. I'll go ahead and fix it on both the development branch and the 5.0 branch.

Changed in kicad:
status: Fix Committed → Triaged
Revision history for this message
Nick Østergaard (nickoe) wrote :

Cool, I will apply that patch on the 5.0.2 windows builds soon

Revision history for this message
tijuca (c-schoenert) wrote :

@Matthias

My complaint wasn't about your post, but even your added entry isn't holding the platform information you are on. ;)

Revision history for this message
Bernhard (schlimmchen) wrote :

(Sorry, I had an old email address set up. Will follow the comments more promptly now, hopefully.)

Unfortunately I am unable to really follow the details in this conversation... Let me provide what I think might be helpful:

Yes, I use 5.0.2+dfsg1-1~bpo9+1 from stretch-backports on debian stretch.

The issue also occurs with kicad "Version: (5.0.2)-1, release build" on Windows 10 x64 (which is identified as Windows 8 in the kicad "About" dialog?!).

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.