A core dump is a file that's generated by the OS and includes a snapshot of the process state. It's useful when e.g. one is not able to run the program under a debugger. Enabling it depends on the OS, I would just search for enable core dumps on "my OS".

If one can run the target program under a debugger, a core dump is not so helpful because it's a static snapshot, whereas a debugger can modify program state.

I am guessing that one has to run the python process itself under the debugger and pass the parameters such as the script path.

There will probably be a signal or exception condition at one point and one can take a look at the call stack. The call stack will probably be messy, as it will include python internals.

An alternative way to debug this is to understand the lifetimes and preconditions of C++ widgets and signals and slots and review one's python code.

Unless there's a bug in Qt itself, PyQt and Qt might have a misunderstanding about lifetimes and something gets cleaned up too soon or there's a dangling refrence to a cleaned up object

There is a gdb plugin for Python. I'm not sure how other distros handle it, but on Arch Linux you have to build Python yourself for it to work.

It should create a coredump on crash by default (either in the current directory or in a OS specific system directory, try /var/cores for example). If it doesn't, try 'ulimit -c unlimited' in your shell to enable coredumps for that session.

Valgrind is not really useful for debugging crashes. Running under gdb would work though.

IMHO Valgrind is immensely useful for debugging crashes.