Sporadic Crash on exit during callq in QObject::disconnect
S4 - Minor
Sorry I can't be more helpful. This is similar to #99606: sporadic CRASH on exit in QNetworkConfigurationManagerPrivate::pollEngines() on unixes (corrupt stack?) in that it occurs on exit, so is not a serious issue, but still a segfault is a segfault. It will be difficult to know what is going on because is sporadic and because I'm only getting disassembler for the qt portion of the code. Note I'm running Arch Linux x86-64 Qt 5.6 inside QtCreator in debug mode, currently latest master a65f06b
1 QObject::disconnect(QObject const *, const char *, QObject const *, const char *) 0x7fffef488ab7 2 ?? 0x7fffe011bf78 3 ?? 0x7fffe010cb36 4 ?? 0x7fffef284de8 5 start_thread 0x7ffff480e424 6 clone 0x7fffee988cbd
Current dissabemly line of failure is line 130 of QObject:;disconnect:
0x7fffef488ab7 <+0x0277> ff 10 callq *(%rax)
Last time this happened, yesterday, I believe, was same line and similar value of rax.
Ok, well I install qt debug symbols, and now have a slightly more useful call stack:
and I found where that segfaulting callq occurs now:
So I believe that callq corresponds to this line:
which is the ending metaObject() of these lines:
Could that mean that sender is an invalid object at that point?
for reference, rax=0x00007fffccf68110 this time...
I'm noticing that most of the deconstructors aren't being called. For instance if I put a breakpoint in Startcenter::~Startcenter(), I never see it caught before I get this crash. I'm going to try adding a bunch of deletions to MuseScore::~MuseScore(), including startcenter.
I'm wondering if this is a bug with Qt 5.6, and not MuseScore. I don't really have much contect for this bug other than that call stack. All the mscore threads are in pthread_con_wait when this crash occurs.
On another note, I was wondering if the bug was somehow related to proper deallocation of memory. I've been looking at a lot of musescore deconstructor and note that sometimes deconstructors don't ever get called. And some musescore classes over-use pointers/dynamic allocation when would be better of just sticking to static allocation, which would ensure the objects no longer exist when their parent object is deleted.
I'm not a musescore user, but I've also seen this crash (100% reproducible) since updating to Qt 5.6 with my PyQt application.
I've now reported it upstream: https://bugreports.qt.io/browse/QTBUG-52988
(also, the issue tracker forces me to select a version for the issue... heh)
I'm making a note that Joachim Backes running Fedora 25 has reported a similar stack trace in #183441: mscore --long-version dumps core. (I've marked his issue as "duplicate" of this.)
That duplicate issue gave me an idea of running musescore --long-version in an infinite bash loop:
I have yet to run into a crash on 3.0 d19dd40 on my Arch Linux Mate machine running Qt 5.8.0 from arch linux repo. Could it be that Qt fixed this bug in their latest version?
I'm also testing with "Version 2.1.0; Build d4ea241" or "Version 2.0.3; Build 3543170" and I have yet to get a segfault.
It sounds like this issue might have been on Qt's end, and that they apparently have fixed it. So I'm going to mark this as "won't fix" to indicate that it doesn't seem like MuseScore devs need to worry about fixing this. People will just have to wait to get the newer Qt version. Does that sound appropriate?
Wait a minute, I found a couple crashes while running 2.1 in infinite loop:
But I'll leave this as "won't fix" since it seems thanks to The Compiler reporting the issue https://bugreports.qt.io/browse/QTBUG-52988 that Qt people are working on it...for reference this is the current state of the bug in their issue tracker:
I should note that when I execute the 2.1 app image, that I'm actually using an earlier Qt library that is embedded in the app image. Sot that might explain why the app image has produced a segfault, while my self compiled builds on my 5.8 machine haven't produced the segfault.
I have yet to get any segfaults while running the infinite loop for the 3.0 AppImage build d19dd40. Since MuseScore 3.0 AppImages should be bundled with Qt 5.8, that probably explains the lack of segfault for 3.0 AppImages.
When I invoke gdb mscore on the debug version, gdb informs me that a large number of the debuginfo packages for required libraries are out of date with a very large number of messages like
I want to install the appropriate debuginfo packages, however the tool provided with Fedora Linux, namely
applies to an RPM **Package Spec** and not to a binary.
Is there a convenient way to install the needed debuginfo files from the binary and not from the package?
I don't know, and I don't see how is relevant to this. Often you could find debug packages for libraries via your dirsto's package manager, and those will work nicely with gdb, although it is harder to setup debug packages if you installed binary versions of a library.