Comment by ffjffsfr | Hacker News Reader

Comment by ffjffsfr | Hacker News Reader

Parent Full thread

I have some experience building PyQt apps and can confirm random crashes (segfaults, sigaborts and such). I suspect this has nothing to do with lambdas. It may likely be something happening between Python and QT - remember that all things happening in QT/C++ world are invisible to Python. For example if your Python routine returns None (as many Python methods, functions do) instead of some other object that is expected by C++ (say QNetworkRequest) it may crash and die without any traceback. I spend hours on things like this - QT method must return something but in some cases was not returning expected object and whole thing was crashing. Python being Python doesn't care about return types, there is no Python traceback, you're left in the dark groping, browsing codebase trying to find what might get wrong, no debugger will help you.

Working with QT bindings is very difficult. Debuging things is not easy. I'm not sure if using bindings is worth it. I suspect doing things in plain C++ QT might be easier to debug and maintain.

In C++ one gets a compilation error if the wrong type is returned from a function.

Qt is generally type safe, but it uses quite a lot of pointer types and also a rather unusual for C++ parent-child resource cleanup rule for QObjects (e.g. all widgets).

When something does crash, C++ doesn't offer any tracebacks, but if one has a core dump or can reproduce the crash under a debugger, a traceback can be easily obtained in the majority of cases.

> but if one has a core dump or can reproduce the crash under a debugger, a traceback can be easily obtained in the majority of cases.

how do you create core dump? starting program under some debugger? I tried debugging with valgrind but the output contained so much noise it took my ages to find something. I also had to recompile QT used by PyQT because QT because QT requires some flags to be able to debug. What's the best way to debug things like this?

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.

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.

I hit some crashes with PyQt which were fixed if the Python slots were defined with "@slot". I think this may be now fixed.

You mean PyQtSlot? http://pyqt.sourceforge.net/Docs/PyQt5/signals_slots.html#Py...

Reply on news.ycombinator.com