Does efence play nice with Qt? If not, what other tools for SIGSEGVs in Qt desktop apps?
-
Trying to debug some
SIGSEGV
s in a desktop app on Ubuntu 14.04.Debug build, linked with
efence
, launched the app withLD_PRELOAD=libefence.so.0.0 ./app_name
, got aSIGSEGV
right away with a core-dump, loaded it in gdb and I can't believe my eyes: the backtrace accusesQByteArray:::append(char)
in the init sequence.So, before heading to the bugs page, my question: is using
efence
(to diagnose memory trashing - not interested in leaks) supported with Qt desktop apps? If not, what other tools would play nice?Thanks.
-
@acolomitchi Not sure why you need something special to debug SIGSEGV. You already have core-dump. In GDB check which part of your code was executed last before crash. In most cases the problem is in own code, not Qt or other libraries.
-
Not sure why you need something special to debug SIGSEGV
Because heavy multithreading, possible race conditions, by the time the app crashes it's too late to find the culprit. (please don't tell me that you believe memory fencing is just an excentricity).
In GDB check which part of your code was executed last before crash.
The crash happens only in Release mode - with -O2 and -O3 - and only by shaking madly that application out of the normal load for, say, about 10-15 mins if one is lucky. (I'm struggling now to provoke another crash).
Even when I compile the code with -g (in Release mode), the gdb trace isn't going to be helpful.
-
In GDB check which part of your code was executed last before crash.
There you go. Please tell me which part of my code caused the crash.
Program terminated with signal SIGSEGV, Segmentation fault. #0 __memmove_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1657 1657 ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S: No such file or directory. (gdb) bt #0 __memmove_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1657 #1 0x00007f1b6673cc9b in ?? () from /home/acolomitchi/bin/Qt/5.7/gcc_64/lib/libQt5Charts.so.5 #2 0x00007f1b6673d20b in ?? () from /home/acolomitchi/bin/Qt/5.7/gcc_64/lib/libQt5Charts.so.5 #3 0x00007f1b651e961a in QObject::event(QEvent*) () from /home/acolomitchi/bin/Qt/5.7/gcc_64/lib/libQt5Core.so.5 #4 0x00007f1b66242062 in QGraphicsObject::event(QEvent*) () from /home/acolomitchi/bin/Qt/5.7/gcc_64/lib/libQt5Widgets.so.5 #5 0x00007f1b65f6652c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /home/acolomitchi/bin/Qt/5.7/gcc_64/lib/libQt5Widgets.so.5 #6 0x00007f1b65f6d220 in QApplication::notify(QObject*, QEvent*) () from /home/acolomitchi/bin/Qt/5.7/gcc_64/lib/libQt5Widgets.so.5 #7 0x00007f1b651c0ae0 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /home/acolomitchi/bin/Qt/5.7/gcc_64/lib/libQt5Core.so.5 #8 0x00007f1b651c351b in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /home/acolomitchi/bin/Qt/5.7/gcc_64/lib/libQt5Core.so.5 #9 0x00007f1b6520dc53 in ?? () from /home/acolomitchi/bin/Qt/5.7/gcc_64/lib/libQt5Core.so.5 #10 0x00007f1b611bbe04 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 ---Type <return> to continue, or q <return> to quit--- #11 0x00007f1b611bc048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #12 0x00007f1b611bc0ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #13 0x00007f1b6520e047 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /home/acolomitchi/bin/Qt/5.7/gcc_64/lib/libQt5Core.so.5 #14 0x00007f1b651bedca in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /home/acolomitchi/bin/Qt/5.7/gcc_64/lib/libQt5Core.so.5 #15 0x00007f1b651c6bad in QCoreApplication::exec() () from /home/acolomitchi/bin/Qt/5.7/gcc_64/lib/libQt5Core.so.5 #16 0x0000000000409131 in main (argc=1, argv=<optimised out>) at ../../src/main.cpp:56
-
@acolomitchi In your first post you wrote QByteArray:::append(char) causes the crash. In the back-trace you posted there is no mention of QByteArray. Can you post the first back-trace?
-
@jsulm Sure, have a look on QTBUG-57556, it's already there along with the description on how to repro.
To be clear:
- I was trying to find a way to diagnose the cause of crash in my app, therefore I chose to use efence/duma
- except that, when I plugged-in either of them, I didn't get to "my" crash, the application crashed on the init stage
The above means: at no point I said that my application crashes because of the
QByteArray::append(char)
, I only asked here "does anyone knows if efence/duma can be used for diagnosing SIGSEGVs in Qt applications?"As an acute attack of pedantry: if efence/duma are indeed usable with Qt, then I cannot discount my application crashing because of
QByteArray::append(char)
screwing up a byte or two of memory at early stages. -
Conclusions of the investigations:
-
DUMA - not usable, has bugs - latest contributions are old enough for me to assume it is not maintained anymore
-
efence - may be used (it won't interfere too much with the normal functionality of the app), will need launching with the EF_ALIGNMENT=8 or 16 for modern architectures (see the "Word-alignment and Overrun Detection" section in libefence's man page and malloc alignment consideration in glibc
This is not to say that using efence will solve your SIGSEGV problems for sure, but it seems the use of it does not harm the execution of bug-free Qt applications.
-
-
You can be nice. Especially when asking for help.
Manner up.
-
Hi, do you think @acolomitchi is answering rude?
I read it as a good follow up on what he found trying to use external tools to
find crash reason. Also provides info on how to make it work with efence.:)
-
@mrjj
Perhaps I am misinterpereting then. -
@BjornW
Well its always a language thing. I am a Dane so the words might sound
differently for me (in the head)
as does to you when in your native language :)
Anyway, not super important, i just wondered as i didn't get that impression but
it could also just be me :)