Sporadic Crash on exit during callq in QObject::disconnect

• Apr 11, 2016 - 21:07
Reported version
2.1
Type
Functional
Severity
S4 - Minor
Status
active
Project

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

Callstack:

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)

where rax=0x00007fffcce19f50
Last time this happened, yesterday, I believe, was same line and similar value of rax.


Comments

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?

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.

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?

Status (old) active won't fix

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.

Status (old) won't fix active
Reported version 3.0 2.2

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

warning: the debug information found in "/usr/lib/debug//lib64/libX11.so.6.3.0.debug" does not match "/lib64/libX11.so.6" (CRC mismatch).

I want to install the appropriate debuginfo packages, however the tool provided with Fedora Linux, namely

dnf debuginfo-install (pkg-spec)

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.