Sporadic Crash on exit during callq in QObject::disconnect

Ok, well I install qt debug symbols, and now have a slightly more useful call stack:

1	QObject::disconnect	qobject.cpp	2949	0x7fffef487ab7	
2	QObject::disconnect	qobject.h	361	0x7fffe011bf78	
3	QDBusConnectionPrivate::closeConnection	qdbusintegrator.cpp	1126	0x7fffe011bf78	
4	QDBusConnectionManager::run	qdbusconnection.cpp	191	0x7fffe010cb36	
5	QThreadPrivate::start	qthread_unix.cpp	340	0x7fffef283de8	
6	start_thread			0x7ffff480d424	
7	clone			0x7fffee987cbd	

and I found where that segfaulting callq occurs now:

        2949 [1]	in kernel/qobject.cpp
0x7fffef487ab1  <+0x0271>        49 8b 06                       mov    (%r14),%rax
0x7fffef487ab4  <+0x0274>        4c 89 f7                       mov    %r14,%rdi
0x7fffef487ab7  <+0x0277>        ff 10                          callq  *(%rax)
0x7fffef487ab9  <+0x0279>        48 89 84 24 c8 00 00 00        mov    %rax,0xc8(%rsp)

So I believe that callq corresponds to this line:
http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qobject.cp…

which is the ending metaObject() of these lines:

    /* We now iterate through all the sender's and receiver's meta
     * objects in order to also disconnect possibly shadowed signals
     * and slots with the same signature.
    */
    bool res = false;
    const QMetaObject *smeta = sender->metaObject();

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 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:

while true; 
 do
  ./MuseScoreNightly-201703222023-master-d19dd40-x86_64.AppImage --long-version;
 done

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:

MuseScore: Music Score Editor
Unstable Prerelease for Version 2.1.0; Build d4ea241
/tmp/.mount_xDWHPi/AppRun: line 18: 21660 Segmentation fault      (core dumped) "${APPDIR}/bin/mscore-portable-nightly" "$@"
MuseScore: Music Score Editor
Unstable Prerelease for Version 2.1.0; Build d4ea241
MuseScore: Music Score Editor
Unstable Prerelease for Version 2.1.0; Build d4ea241
MuseScore: Music Score Editor
Unstable Prerelease for Version 2.1.0; Build d4ea241
MuseScore: Music Score Editor
Unstable Prerelease for Version 2.1.0; Build d4ea241
MuseScore: Music Score Editor
Unstable Prerelease for Version 2.1.0; Build d4ea241
MuseScore: Music Score Editor
Unstable Prerelease for Version 2.1.0; Build d4ea241
MuseScore: Music Score Editor
Unstable Prerelease for Version 2.1.0; Build d4ea241
/tmp/.mount_tf4Yka/AppRun: line 18: 21794 Segmentation fault      (core dumped) "${APPDIR}/bin/mscore-portable-nightly" "$@"

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:

P1: Critical
Resolution: Unresolved
Affects Version/s:
5.6.0, 5.6.1, 5.7.0

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.

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.