Nightly 7.99 Crash when opening page 2 of demo schematic kit-dev-coldfire-xilinx_5213

hmk · February 13, 2023, 9:51pm

Does someone else get a crash of KiCad when opening the demo project “kit-dev-coldfire-xilinx_5213” and going to any page of the schematic using the schematic hierarchy navigator?

Start Kicad nightly
In project manager File → Open demo project…
Go into folder kit-dev-coldfire-xilinx_5213 and open the project file
In project manager, open schematic
In Schematic hierarchy navigator on the left, klick page 1, page 2 or page 3.
KiCad crashes.

7.0 stable works, it doesn’t crash.

If you open another demo project named complex_hierarchy in 7.99 nightly, the schematic hierarchy navigator works and KiCad doesn’t crash when you klick the different pages.

bild

Application: KiCad x86_64 on x86_64

Version: 7.99.0-1.20230213git8bab429.fc37, release build

Libraries:
wxWidgets 3.2.1
FreeType 2.12.1
HarfBuzz 5.2.0
FontConfig 2.14.1
libcurl/7.85.0 OpenSSL/3.0.8 zlib/1.2.12 brotli/1.0.9 libidn2/2.3.4 libpsl/0.21.1 (+libidn2/2.3.3) libssh/0.10.4/openssl/zlib nghttp2/1.51.0

Platform: Fedora release 37 (Thirty Seven), 64 bit, Little endian, wxGTK, KDE, wayland

Build Info:
Date: Feb 13 2023 18:16:46
wxWidgets: 3.2.1 (wchar_t,wx containers) GTK+ 3.24
Boost: 1.78.0
OCC: 7.6.3
Curl: 7.85.0
ngspice: 39
Compiler: GCC 12.2.1 with C++ ABI 1017

Build settings:
KICAD_SPICE=ON

marekr · February 13, 2023, 11:42pm

I mean, it’s the nightly and the start of the next development cycle. Expect it to have new crashes as a feature daily heh.

davidsrsb · February 14, 2023, 12:01am

For the next few months the focus on 7.99 should be adding features that might break something, no need for stability at all

hmk · February 14, 2023, 12:53am

Of course I expect instability in this phase.
The question I have though, is whether the intention or philosophy of the project is to fix the bugs along the way, or keep them until the end of the version development cycle, like november-december 2023?

paulvdh · February 14, 2023, 1:19am

You’ll have to find some balance.
It is of course appreciated if you want to test drive nightlies, but you also have to consider that the developers time is spent more effectively when they are actually coding instead of reading bug reports. At the moment I don’t even have the stable V7.0 yet myself.

At this moment it is very likely that those developers are still switching themselves and it’s quite likely they are aware of a bunch of bugs that are not reported anywhere and just have not had time to fix them. Even KiCad developers are mere humans, at least, I think so, most of them anyway…

retiredfeline · February 14, 2023, 3:09am

Somewhere in between? TL;DR: It depends.

You’re asking for intentions and philosophy. I don’t think it’s that organised or hard and fast. I don’t see why it would be any different from the normal bugfix process. First the bug has to be confirmed. So it helps if it’s easily reproducible across the platforms. Even better if you can submit a traceback. And get people to vote for the issue. Then it has to be triaged. It it a showstopper that prevents work? Or affects only a few cases? Is somebody free to look at it? Maybe there are more pressing things to work on. On the other hand a developer may say, aha I know exactly what causes that and it’ll be fixed before you know it.

Just report it and trust the process.

hmk · February 14, 2023, 1:31pm

Does the following make any sense, or am I completely in the dark?

I haven’t worked with debugging before, unfortunately…

I ran “sudo coredumpctl gdb”, and that is the tail end of the output, after it has given a lot of mesages about metadata it had found for different messages…

There are of course the raw core dump files, but those are 19MB or so.

            Stack trace of thread 77707:
            #0  0x00007f1d6d575908 __memcpy_avx_unaligned_erms (libc.so.6 + 0x152908)
            #1  0x00007f1d40f7d4db _ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE9_M_assignERKS4_ (_eeschema.kiface + 0x57d4db)
            #2  0x00007f1d411d7e87 _ZN14SCH_EDIT_FRAME28RefreshOperatingPointDisplayEv (_eeschema.kiface + 0x7d7e87)
            #3  0x00007f1d411ddfa6 _ZN14SCH_EDIT_FRAME19DisplayCurrentSheetEv (_eeschema.kiface + 0x7ddfa6)
            #4  0x00007f1d41521150 _ZN17SCH_NAVIGATE_TOOL11ChangeSheetERK10TOOL_EVENT (_eeschema.kiface + 0xb21150)
            #5  0x00007f1d41715b70 _ZN9COROUTINEIiRK10TOOL_EVENTE10callerStubEl (_eeschema.kiface + 0xd15b70)
            #6  0x00007f1d419f73c1 make_fcontext (_eeschema.kiface + 0xff73c1)
            ELF object binary architecture: AMD x86-64

GNU gdb (GDB) Fedora Linux 12.1-7.fc37
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type “show copying” and “show warranty” for details.
This GDB was configured as “x86_64-redhat-linux-gnu”.
Type “show configuration” for configuration details.
For bug reporting instructions, please see:
https://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.

For help, type “help”.
Type “apropos word” to search for commands related to “word”…
Reading symbols from /usr/lib64/kicad-nightly/bin/kicad…
Reading symbols from /usr/lib/debug/usr/lib64/kicad-nightly/bin/kicad-7.99.0-1.20230213git8bab429.fc37.x86_64.debug…

warning: Can’t open file anon_inode:i915.gem which was expanded to anon_inode:i915.gem during file-backed mapping note processing

warning: Can’t open file /memfd:xshmfence (deleted) during file-backed mapping note processing

warning: Can’t open file anon_inode:i915.gem which was expanded to anon_inode:i915.gem during file-backed mapping note processing

warning: Can’t open file /SYSV00000000 (deleted) during file-backed mapping note processing
[New LWP 77707]
[New LWP 77730]
[New LWP 77727]
[New LWP 77819]
[New LWP 77740]
[New LWP 77739]
[New LWP 77821]
[New LWP 77824]
[New LWP 77742]
[New LWP 77744]
[New LWP 77822]
[New LWP 77735]
[New LWP 77743]
[New LWP 77748]
[New LWP 77820]
[New LWP 77738]
[New LWP 77708]
[New LWP 77823]
[New LWP 77818]
[New LWP 77741]
[New LWP 77825]
[Thread debugging using libthread_db enabled]
Using host libthread_db library “/lib64/libthread_db.so.1”.
Core was generated by `/usr/lib64/kicad-nightly/bin/kicad’.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __memmove_avx_unaligned_erms () at …/sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:374
374 movq %rsi, (%rdi)
[Current thread is 1 (Thread 0x7f1d6af52ac0 (LWP 77707))]
(gdb)

craftyjon · February 14, 2023, 1:36pm

The stack trace part is useful; the rest is just noise. Looks like this is related to the new simulation operating point display that was recently added. If you report a bug, I’m sure Jeff will fix it soon.

hmk · February 14, 2023, 1:38pm

Thanks, I’ll copy the stack trace and the text description from the first message into a report in gitlab.
Issue #13904

system · May 15, 2023, 1:39pm

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.