As I want to help developers to make KiCad even better, I’d like to report bugs I can reproduce. But sometimes KiCad just crashes without a visible reason. Since Raspberry Foundation forced me to use Nightlies, things became more unstable.
For example yesterday KiCad crashed with SIGSEGV signal (taken from Ubuntu crash report) and had not shown anything to me. The only thing I have is the crash report file created by the apport.gtk tool. I don’t know whether this is useful or not.
Any suggestions to report such cases?
Maybe I can execute KiCad with debug symbols loaded so I can catch the SIGSEGV?
P.S: Since the projects that I’m working on are company IP, I can not share them.
The easiest thing is to report what you were doing just before the crash. If you are able to install debug symbols and get a stack trace, that is even better.
You don’t need to share the project but if you can even do something like delete everything but a small section that triggers the bug to share it, that’ll help infinitely more to fixing it. Or making reproduction cases from scratch.
If the problem is reproducible and I could remember what I had done, it is easier to report and create a minimum reproducible example.
But like in this example things build up in time internally and becomes visible without a proper reason. That’s why we need something like a stack trace.
@craftyjon I had installed kicad-nightly-dbg but couldn’t figure out how to run kicad-nightly with gdb and debug symbols loaded. Could you help me with that?
Sorry for the delayed response. Does just running gdb kicad-nightly work? (assuming kicad-nightly is the name of the kicad binary installed by your nightly package) If you get a crash; bt in the GDB console will give you the stack trace
Unfortunately no, it doesn’t work. Since kicad-nightly is just a shell file running kicad with some environment variable, it gives error.
But fortunately I’ve figured out how to run this time.
Enter to the folder of kicad-nightly executables: cd /usr/lib/kicad-nightly/bin
Then run gdb (don’t load kicad now since we’d need some environment vars) gdb
Add first environment variable (gdb) set environment LD_LIBRARY_PATH=/usr/lib/kicad-nightly/lib/x86_64-linux-gnu/:/usr/lib/kicad-nightly/lib/
Add second env. (gdb) set environment KICAD_PATH=/usr/share/kicad-nightly
And third: (gdb) set environment KICAD_CONFIG_HOME="$HOME/.config/kicadnightly"
Load kicad and its debug symbols: (gdb) file kicad
Execute kicad from gdb command line: (gdb) run
Kicad would start with debug symbols loaded.
One thing is not certain for me, though. If I run this style KiCad runs like it is starting for the first time and tries to import settings from stable version. As I’ve already done that, I’m suspecting from a sandbox which gdb creates.
This way kicad would run with all the correct environment variables (previous post has an issue with " set environment KICAD_CONFIG_HOME="$HOME/.config/kicadnightly"" as it was not converting HOME variable to the actual user home folder.
