PDA

View Full Version : Best way to debug crash



sandor
26th September 2012, 19:46
I am having this crash:



Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffbf3f1700 (LWP 7474)]
0x00007ffff754d4ec in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/local/Trolltech/Qt-4.7.4/lib/libQtCore.so.4
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.7.el6_0.5.x86_64 keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.8.2-3.el6_0.7.x86_64 libcom_err-1.41.12-3.el6.x86_64 libgcc-4.4.4-13.el6.x86_64 libselinux-2.0.94-2.el6.x86_64 libstdc++-4.4.4-13.el6.x86_64 libtool-ltdl-2.2.6-15.5.el6.x86_64 mysql-libs-5.1.52-1.el6_0.1.x86_64 nss-softokn-freebl-3.12.7-1.1.el6.x86_64 openssl-1.0.0-4.el6_0.2.x86_64 unixODBC-2.2.14-11.el6.x86_64 zlib-1.2.3-25.el6.x86_64
(gdb) where
#0 0x00007ffff754d4ec in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/local/Trolltech/Qt-4.7.4/lib/libQtCore.so.4
#1 0x00007ffff745be6d in ?? () from /usr/local/Trolltech/Qt-4.7.4/lib/libQtCore.so.4
#2 0x00007ffff745c404 in ?? () from /usr/local/Trolltech/Qt-4.7.4/lib/libQtCore.so.4
#3 0x00000030aae077e1 in start_thread () from /lib64/libpthread.so.0
#4 0x00000030aa6e18ed in clone () from /lib64/libc.so.6
(gdb)


Executable is compiled with all debug (usually shows the exact line if there is a crash. Not now. It is intermittent. Probably something goes out of scope or get deleted. Qt documentation does not have QMetaObject::activate in Qt Assistant documentation.

What is the best way to find the object or line causing this crash (I have plenty of printf s already).

Added after 37 minutes:

Never mind, found and fixed. It was deleteLater() in a QThread subclassed start(). Now deleteLater() is connected to the finish() signal and works fine. Interesting that the issue has happened only on linux, not on windows.

d_stranz
26th September 2012, 19:50
Probably the order of destruction is different in the two implementations. However, the fact that it aborted with a SIGSEGV implies that there is still probably a bug in your implementation, but you have just hidden it with your workaround.