How to create a proper bug report after a crash


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.

@craftyjon and @marekr,

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)

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.

1 Like

OK, I’ve made a simpler one command :slight_smile:

gdb --ex=run --args env LD_LIBRARY_PATH=/usr/lib/kicad-nightly/lib/x86_64-linux-gnu/:/usr/lib/kicad-nightly/lib/ KICAD_PATH=/usr/share/kicad-nightly KICAD_CONFIG_HOME="$HOME/.config/kicadnightly" /usr/lib/kicad-nightly/bin/kicad

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.