Bug 427395

Summary: A custom application using Qt and Phonon (but not KDE) sometimes crashes in Phonon code upon exit
Product: [Unmaintained] phonon-backend-gstreamer Reporter: lthode
Component: generalAssignee: Daniel Vrátil <dvratil>
Status: RESOLVED UNMAINTAINED    
Severity: crash CC: myriam, romain.perier, sitter, tdfischer
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: 4.8   
Platform: RedHat Enterprise Linux   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: Backtrace of the crash (all threads, very mildly redacted to protect the innocent)

Description lthode 2020-10-06 18:27:03 UTC 
Created attachment 132153 [details]
Backtrace of the crash (all threads, very mildly redacted to protect the innocent)

SUMMARY
A custom business application I am working on sometimes crashes (segfaults) on exit with a backtrace that points at an issue within Phonon.  While the application does not crash in a reproducible fashion, the backtraces appear quite similar to those reported in bug #321531 and friends where Digikam was crashing when it attemped to play back AVI media.  The application in question runs on CentOS 7.7.1908 (x86-64) using Phonon 4.6.0, Phonon-GStreamer 4.6.3, and Qt 4.8.7.

An all-threads backtrace, taken from a coredump, is attached.  If you want further symbol information than what's provided, I can install more symbols and reinvestigate the coredump; if you want any other information, just ask here in a comment.
Comment 1 lthode 2020-10-06 18:35:56 UTC 
My investigation of the issue pointed me at a bad metaObject within the devnull NoDebugStream (derived from QIODevice).  Following that trail to gstreamer/debug_p.h led me to notice that the Q_OBJECT macro in NoDebugStream's definition is commented out (in master, even!), which looks wrong since QIODevice is a QObject in the normal case (the only way it isn't is if QT_NO_QOBJECT is defined when qiodevice.h is #included).  Is there a good reason for NoDebugStream to be defined the way it is, or am I onto something here?  (NB: https://marcmutz.wordpress.com/effective-qt/subclassing/ seems to agree with what I am seeing that Q_OBJECT should have been there all along...)
Comment 2 lthode 2020-10-06 18:41:43 UTC 
A bit of a clarification on the investigation -- the bogus metaObject I mentioned stems from the QObject::d pointer within devnull being nullptr (zero-initialized, most likely).
Comment 3 Christoph Feck 2020-11-01 12:31:32 UTC 
Qt4 is long unmaintained.