eeschema crash on open

[Jeff Young]

I've been experiencing random eeschema crashes. I've found one way to reliable reproduce it:

Open a project with a schema in it.
Double-click the schema to open it.
Close the schema.
Repeat until crash.

Usually it crashes on the 3rd time. Sometimes not until the 4th or 5th.

Crash log attached.

Application: kicad
Version: (2017-12-21 revision 158bc0619)-master, release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
Platform: Mac OS X (Darwin 17.3.0 x86_64), 64 bit, Little endian, wxMac
Build Info:
    wxWidgets: 3.0.3 (UTF-8,STL containers,compatible with 2.8)
    Boost: 1.65.1
    Curl: 7.57.0
    Compiler: Clang 9.0.0 with C++ ABI 1002

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

Process: kicad [24242]
Path: /Users/USER/*/kicad.app/Contents/MacOS/kicad
Identifier: org.kicad-pcb.kicad
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: kicad [24242]
User ID: 501

Date/Time: 2017-12-21 13:59:07.706 +0000
OS Version: Mac OS X 10.13.2 (17C88)
Report Version: 12
Anonymous UUID: F61519F4-5589-8F89-7043-2C6A205D30A4

[Wayne Stambaugh (stambaughw)]

This doesn't happen on windows 7 pro at least not until my index finger
got tired of double clicking. It could be an osx specific issue.

On 12/21/2017 9:03 AM, Jeff Young wrote:
> Public bug reported:
>
> I've been experiencing random eeschema crashes. I've found one way to
> reliable reproduce it:
>
> Open a project with a schema in it.
> Double-click the schema to open it.
> Close the schema.
> Repeat until crash.
>
> Usually it crashes on the 3rd time. Sometimes not until the 4th or 5th.
>
> Crash log attached.
>
>
> Application: kicad
> Version: (2017-12-21 revision 158bc0619)-master, release build
> Libraries:
> wxWidgets 3.0.3
> libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
> Platform: Mac OS X (Darwin 17.3.0 x86_64), 64 bit, Little endian, wxMac
> Build Info:
> wxWidgets: 3.0.3 (UTF-8,STL containers,compatible with 2.8)
> Boost: 1.65.1
> Curl: 7.57.0
> Compiler: Clang 9.0.0 with C++ ABI 1002
>
> Build settings:
> USE_WX_GRAPHICS_CONTEXT=ON
> USE_WX_OVERLAY=ON
> KICAD_SCRIPTING=OFF
> KICAD_SCRIPTING_MODULES=OFF
> KICAD_SCRIPTING_WXPYTHON=OFF
> KICAD_SCRIPTING_ACTION_MENU=OFF
> BUILD_GITHUB_PLUGIN=ON
> KICAD_USE_OCE=OFF
> KICAD_SPICE=OFF
>
>
> Process: kicad [24242]
> Path: /Users/USER/*/kicad.app/Contents/MacOS/kicad
> Identifier: org.kicad-pcb.kicad
> Version: ??? (???)
> Code Type: X86-64 (Native)
> Parent Process: ??? [1]
> Responsible: kicad [24242]
> User ID: 501
>
> Date/Time: 2017-12-21 13:59:07.706 +0000
> OS Version: Mac OS X 10.13.2 (17C88)
> Report Version: 12
> Anonymous UUID: F61519F4-5589-8F89-7043-2C6A205D30A4
>
> ** Affects: kicad
> Importance: Undecided
> Status: New
>
>
> ** Tags: eeschema
>
> ** Attachment added: "crash_log.txt"
> https://bugs.launchpad.net/bugs/1739614/+attachment/5025648/+files/crash_log.txt
>

[Jeff Young (jeyjey)]

Could someone on windows try another method of reproducing it:

Open a project with a schema.
Double-click the schema to open it.
Close the schema.

Open a different project.
Crash.

Thanks,
Jeff.

> On 21 Dec 2017, at 17:47, Wayne Stambaugh <email address hidden> wrote:
>
> This doesn't happen on windows 7 pro at least not until my index finger
> got tired of double clicking. It could be an osx specific issue.
>
> On 12/21/2017 9:03 AM, Jeff Young wrote:
>> Public bug reported:
>>
>> I've been experiencing random eeschema crashes. I've found one way to
>> reliable reproduce it:
>>
>> Open a project with a schema in it.
>> Double-click the schema to open it.
>> Close the schema.
>> Repeat until crash.
>>
>> Usually it crashes on the 3rd time. Sometimes not until the 4th or 5th.
>>
>> Crash log attached.
>>
>>
>> Application: kicad
>> Version: (2017-12-21 revision 158bc0619)-master, release build
>> Libraries:
>> wxWidgets 3.0.3
>> libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
>> Platform: Mac OS X (Darwin 17.3.0 x86_64), 64 bit, Little endian, wxMac
>> Build Info:
>> wxWidgets: 3.0.3 (UTF-8,STL containers,compatible with 2.8)
>> Boost: 1.65.1
>> Curl: 7.57.0
>> Compiler: Clang 9.0.0 with C++ ABI 1002
>>
>> Build settings:
>> USE_WX_GRAPHICS_CONTEXT=ON
>> USE_WX_OVERLAY=ON
>> KICAD_SCRIPTING=OFF
>> KICAD_SCRIPTING_MODULES=OFF
>> KICAD_SCRIPTING_WXPYTHON=OFF
>> KICAD_SCRIPTING_ACTION_MENU=OFF
>> BUILD_GITHUB_PLUGIN=ON
>> KICAD_USE_OCE=OFF
>> KICAD_SPICE=OFF
>>
>>
>> Process: kicad [24242]
>> Path: /Users/USER/*/kicad.app/Contents/MacOS/kicad
>> Identifier: org.kicad-pcb.kicad
>> Version: ??? (???)
>> Code Type: X86-64 (Native)
>> Parent Process: ??? [1]
>> Responsible: kicad [24242]
>> User ID: 501
>>
>> Date/Time: 2017-12-21 13:59:07.706 +0000
>> OS Version: Mac OS X 10.13.2 (17C88)
>> Report Version: 12
>> Anonymous UUID: F61519F4-5589-8F89-7043-2C6A205D30A4
>>
>> ** Affects: kicad
>> Importance: Undecided
>> Status: New
>>
>>
>> ** Tags: eeschema
>>
>> ** Attachment added: "crash_log.txt"
>> https://bugs.launchpad.net/bugs/1739614/+attachment/5025648/+files/crash_log.txt
>>
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1739614
>
> Title:
> eeschema crash on open
>
> Status in KiCad:
> New
>
> Bug description:
> I've been experiencing random eeschema crashes. I've found one way to
> reliable reproduce it:
>
> Open a project with a schema in it.
> Double-click the schema to open it.
> Close the schema.
> Repeat until crash.
>
> Usually it crashes on the 3rd time. Sometimes not until the 4th or
> 5th.
>
> Crash log attached.
>
>
> Application: kicad
> Version: (2017-12-21 revision 158bc0619)-master, release build
> Libraries:
> wxWidgets 3.0.3
> libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
> Platform: Mac OS X (Darwin 17.3.0 x86_64), 64 bit, Little endian, wxMac
> Build Info:
> wxW...

[Wayne Stambaugh (stambaughw)]

I just tested this on Debian testing using the previous method and the
latest method in an attempt to get it to crash and it doesn't crash so
this is looking more and more like an macos specific issue.

On 12/22/2017 07:25 AM, Jeff Young wrote:
> Could someone on windows try another method of reproducing it:
>
> Open a project with a schema.
> Double-click the schema to open it.
> Close the schema.
>
> Open a different project.
> Crash.
>
> Thanks,
> Jeff.
>
>
>> On 21 Dec 2017, at 17:47, Wayne Stambaugh <email address hidden> wrote:
>>
>> This doesn't happen on windows 7 pro at least not until my index finger
>> got tired of double clicking. It could be an osx specific issue.
>>
>> On 12/21/2017 9:03 AM, Jeff Young wrote:
>>> Public bug reported:
>>>
>>> I've been experiencing random eeschema crashes. I've found one way to
>>> reliable reproduce it:
>>>
>>> Open a project with a schema in it.
>>> Double-click the schema to open it.
>>> Close the schema.
>>> Repeat until crash.
>>>
>>> Usually it crashes on the 3rd time. Sometimes not until the 4th or 5th.
>>>
>>> Crash log attached.
>>>
>>>
>>> Application: kicad
>>> Version: (2017-12-21 revision 158bc0619)-master, release build
>>> Libraries:
>>> wxWidgets 3.0.3
>>> libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
>>> Platform: Mac OS X (Darwin 17.3.0 x86_64), 64 bit, Little endian, wxMac
>>> Build Info:
>>> wxWidgets: 3.0.3 (UTF-8,STL containers,compatible with 2.8)
>>> Boost: 1.65.1
>>> Curl: 7.57.0
>>> Compiler: Clang 9.0.0 with C++ ABI 1002
>>>
>>> Build settings:
>>> USE_WX_GRAPHICS_CONTEXT=ON
>>> USE_WX_OVERLAY=ON
>>> KICAD_SCRIPTING=OFF
>>> KICAD_SCRIPTING_MODULES=OFF
>>> KICAD_SCRIPTING_WXPYTHON=OFF
>>> KICAD_SCRIPTING_ACTION_MENU=OFF
>>> BUILD_GITHUB_PLUGIN=ON
>>> KICAD_USE_OCE=OFF
>>> KICAD_SPICE=OFF
>>>
>>>
>>> Process: kicad [24242]
>>> Path: /Users/USER/*/kicad.app/Contents/MacOS/kicad
>>> Identifier: org.kicad-pcb.kicad
>>> Version: ??? (???)
>>> Code Type: X86-64 (Native)
>>> Parent Process: ??? [1]
>>> Responsible: kicad [24242]
>>> User ID: 501
>>>
>>> Date/Time: 2017-12-21 13:59:07.706 +0000
>>> OS Version: Mac OS X 10.13.2 (17C88)
>>> Report Version: 12
>>> Anonymous UUID: F61519F4-5589-8F89-7043-2C6A205D30A4
>>>
>>> ** Affects: kicad
>>> Importance: Undecided
>>> Status: New
>>>
>>>
>>> ** Tags: eeschema
>>>
>>> ** Attachment added: "crash_log.txt"
>>> https://bugs.launchpad.net/bugs/1739614/+attachment/5025648/+files/crash_log.txt
>>>
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1739614
>>
>> Title:
>> eeschema crash on open
>>
>> Status in KiCad:
>> New
>>
>> Bug description:
>> I've been experiencing random eeschema crashes. I've found one way to
>> reliable reproduce it:
>>
>> Open a project with a schema in it.
>> Double-click the schema to open it.
>> Close the schema.
>> Repeat until crash.
>>
>> Usually it crashes on the 3rd time. Sometimes not until th...

[jean-pierre charras (jp-charras)]

I tried of W7 - 32 bits.

No crash.

[Jeff Young (jeyjey)]

This is the commit which introduced the crash on OSX:

Keep LIB_ID and LIB_PART name/library in sync
Updates LIB_ID::LibItemName field when a part is renamed and LIB_PART
name when a new LIB_ID is set.

Similarly, LIB_ID::LibNickName field is updated when a library set, but
there is no easy way to assign library when LIB_ID::LibNickName is
modified.

https://git.launchpad.net/kicad/commit/?id=445ac505886528951e1d66fde20f2545af7a53c1

[Wayne Stambaugh (stambaughw)]

I see the problem. Using PART_LIB is no longer valid because the
library file name without extension may not actually be the nickname
used in the symbol library table so the LIB_ID could be wrong. @Orson,
assigning the LIB_ID nickname this way is invalid. You should not be
setting the LIB_PART library pointer to PART_LIB any more. Only
LIB_PART objects in the cache library get this treatment because it is
maintained outside the symbol library table. All other LIB_PART objects
loaded into libraries defined in the symbol library table do not. The
PART_LIB pointer should be nullptr.

On 12/22/2017 05:39 PM, Jeff Young wrote:
> This is the commit which introduced the crash on OSX:
>
> Keep LIB_ID and LIB_PART name/library in sync
> Updates LIB_ID::LibItemName field when a part is renamed and LIB_PART
> name when a new LIB_ID is set.
>
> Similarly, LIB_ID::LibNickName field is updated when a library set, but
> there is no easy way to assign library when LIB_ID::LibNickName is
> modified.
>
> https://git.launchpad.net/kicad/commit/?id=445ac505886528951e1d66fde20f2545af7a53c1
>

[Maciej Suminski (orsonmmz)]

Hi Wayne,

I understand your point and I agree it needs to be corrected, but I do not understand why it became wrong with the patch applied, as the LIB_PART assignment was anyway there (the first removed line in LIB_PART constructor).

[Wayne Stambaugh (stambaughw)]

Hey Orson,

I haven't looked over your symbol library editor changes so maybe the
crash is not related to this. However, you should not be setting the
PART_LIB* of any LIB_PART except for LIB_PARTs that are in the cache
library. The crash dump would suggest that there might be a bad
filename being passed to the SCH_LEGACY_PLUGIN::Load method.

Cheers,

Wayne

On 12/23/2017 03:01 PM, Maciej Suminski wrote:
> Hi Wayne,
>
> I understand your point and I agree it needs to be corrected, but I do
> not understand why it became wrong with the patch applied, as the
> LIB_PART assignment was anyway there (the first removed line in LIB_PART
> constructor).
>
> ** Changed in: kicad
> Assignee: (unassigned) => Maciej Suminski (orsonmmz)
>
> ** Changed in: kicad
> Importance: Undecided => Critical
>

[Jeff Young (jeyjey)]

Attached is a -temporary- workaround to the OSX crashes.

When wxLogTrace() is called, the LIB_PART's m_aliases[] member variable is NULL, and GetName() blindly accesses the first member in the array.

(Aside from anything else, it seems like LIB_PART::GetName() should be fixed to not assume m_aliases has items?)

[KiCad Janitor (kicad-janitor)]

Fixed in revision 51717aad220dc4ca3554e83aac4e98b8dd927d28
https://git.launchpad.net/kicad/patch/?id=51717aad220dc4ca3554e83aac4e98b8dd927d28

[Wayne Stambaugh (stambaughw)]

@Jeff, you work around is not the ideal answer. I just pushed a change that tests for an empty alias list before attempting to access the first alias object pointer in the list. This will fix the crash and raise and assertion on debug builds when this condition occurs. What bugs me about this is how this is even happening. The LIB_PART ctor always creates a new LIB_ALIAS for the root part so I'm not sure how this even happened. Given that this code has been in place for a long time and has never crashed before, I'm a bit concerned that we've added some code that broke this behavior. Hopefully the assertion will help us flush this out.

[Jeff Young (jeyjey)]

@Wayne, I absolutely agree. (That's why I marked it as "temporary" -- it was just meant to allow folks on OSX to work with the nightly builds.)

[Jeff Young (jeyjey)]

BTW, there's not much in that commit I flagged earlier, and it crashes with it and not without it.

[Jeff Young (jeyjey)]

@Wayne, I applied your changes, and it goes down pretty quick. I'm not sure it provides any extra info, though; the stack-trace is pretty much the same as before.

Hmm... wxWidgets debug alert is useless. There's no way to copy the stack trace out, nor grow the window wide enough to be able to read it....

OK, there is one interesting bit of info: it doesn't fail on a single (or a couple) of corrupt LIB_PARTS. It asserted at least 30 times before I got tired of waiting for wxWidgets to collect stacktrace info.

[Jeff Young (jeyjey)]

I suppressed additional debug dialogs and counted the number of asserts in the application output: it asserted 1774 times with the following libraries loaded:

 power
 device
 transistors
 conn
 linear
 regul
 74xx
 cmos4000
 adc-dac
 memory
 xilinx
 microcontrollers
 dsp
 microchip
 analog_switches
 motorola
 texas
 intel
 audio
 interface
 digital-audio
 philips
 display
 cypress
 siliconi
 opto
 atmel
 contrib
 valves

[Wayne Stambaugh (stambaughw)]

@Jeff, this assertion does not mean that the segfault bug is not fixed.
It' only means that alias list is empty when the LIB_PART dtor is
called. I need to look into it to figure out why this is happening. If
you are still getting a segfault after the assertion message, then I
made a mistake in my GetName() method changes. If you are not getting a
segfault, then the bug is fixed so please restore the status to fix
committed. The assertion is a different bug and a separate bug report
should be filed. Even though they are related they are not the same bug
and bug reports should only be for a single bug or they become difficult
to close out.

On 12/30/2017 07:31 AM, Jeff Young wrote:
> I suppressed additional debug dialogs and counted the number of asserts
> in the application output: it asserted 1774 times with the following
> libraries loaded:
>
> power
> device
> transistors
> conn
> linear
> regul
> 74xx
> cmos4000
> adc-dac
> memory
> xilinx
> microcontrollers
> dsp
> microchip
> analog_switches
> motorola
> texas
> intel
> audio
> interface
> digital-audio
> philips
> display
> cypress
> siliconi
> opto
> atmel
> contrib
> valves
>

[Jeff Young (jeyjey)]

@Wayne: no segfault; just the asserts.

New bug: https://bugs.launchpad.net/kicad/+bug/1740597