Summary: | don't construct broken MOs when init failed | ||
---|---|---|---|
Product: | [Frameworks and Libraries] phonon-backend-gstreamer | Reporter: | Stou Sandalski <stou> |
Component: | general | Assignee: | Harald Sitter <sitter> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | caulier.gilles, myriam, romain.perier, sakisdesonic, tdfischer |
Priority: | NOR | ||
Version: | 4.6.2 | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/phonon-gstreamer/002b786f97d8e274691d78355e35f603c78c5963 | Version Fixed In: | 4.6.3 |
Description
Stou Sandalski
2012-11-20 06:30:56 UTC
Ohhhhh, that actually is a phonon gstreamer crash.
Please check your terminal output. Your GStreamer installation seems to be corrupted.
And here I thought the crash made no sense...
As usual everything in libphonon is working as expected and is 0 ptr save, phonon-gstreamer however....
Pipeline::isSeekable is called by MediaObject::isSeekable (ahoy captain obvious) and the ctor of that essentially goes:
>> if (!m_backend->isValid()) {
>> setError(tr("Cannot start playback. \n\nCheck your GStreamer installation and make sure you "
>> "\nhave libgstreamer-plugins-base installed."), Phonon::FatalError);
>> } else {
>> m_root = this;
>> m_pipeline = new Pipeline(this);
Which translates to: if the gstreamer cache is broken we are happily going to crash, else don't crash. Of course that makes no sense at all since we have support for broken backend in libphonon already (i.e. interface calls are always protected by if(d->m_backendObject)) so the right thing to do here is not to render this instance of the MO erronous (what with it actually calling out to the Backend to see whether it is - Backend is a singleton and that var is set once, so if it is for this MO it is for every MO...) but in fact not construct one at all.
In particular the createObject function of the Backend must always return 0 when m_isValid is not true. Point being that since libgstreamer could not init the backend can do absolutely nothing. The user would be non-thewiser about it not working, but at least it does not crash.
Git commit eedf74fcbd442f97d9297400a12eeb95fd4e166b by Harald Sitter. Committed on 03/12/2012 at 14:38. Pushed by sitter into branch '4.6'. don't construct objects when gst init failed what happend is that we continued constructing backend objects even when gst init failed (supposedly that is only the case since the pipeline refactor) which in turn lead to crashing as it would have required just about every function to do validity checking before doing anything at all. the good news is that libphonon already does that as part of its own validity system. whenver the backend returns 0 on an object construction request libphonon's corresponding frontend object will simply ignore all calls thus allowing a scenario in which the backend cannot construct any valid backend objects (such as when gst init fails). consequently also remove pointless checks for the validity in the AO, MO and devicemanager ctors. also the managers are now only constructed if gst_init was successful. ultimate result of this is that when gst_init failed or our plugin requirements are not met (i.e. gst-base is not present) no object will get constructed other than the Backend object itself. Conflicts: gstreamer/devicemanager.cpp gstreamer/mediaobject.cpp M +28 -29 gstreamer/audiooutput.cpp M +11 -5 gstreamer/backend.cpp M +3 -2 gstreamer/backend.h M +47 -51 gstreamer/devicemanager.cpp M +36 -47 gstreamer/mediaobject.cpp http://commits.kde.org/phonon-gstreamer/eedf74fcbd442f97d9297400a12eeb95fd4e166b Git commit 002b786f97d8e274691d78355e35f603c78c5963 by Harald Sitter. Committed on 03/12/2012 at 14:31. Pushed by sitter into branch 'master'. don't construct objects when gst init failed what happend is that we continued constructing backend objects even when gst init failed (supposedly that is only the case since the pipeline refactor) which in turn lead to crashing as it would have required just about every function to do validity checking before doing anything at all. the good news is that libphonon already does that as part of its own validity system. whenver the backend returns 0 on an object construction request libphonon's corresponding frontend object will simply ignore all calls thus allowing a scenario in which the backend cannot construct any valid backend objects (such as when gst init fails). consequently also remove pointless checks for the validity in the AO, MO and devicemanager ctors. also the managers are now only constructed if gst_init was successful. ultimate result of this is that when gst_init failed or our plugin requirements are not met (i.e. gst-base is not present) no object will get constructed other than the Backend object itself. M +28 -29 gstreamer/audiooutput.cpp M +11 -5 gstreamer/backend.cpp M +3 -2 gstreamer/backend.h M +54 -58 gstreamer/devicemanager.cpp M +39 -50 gstreamer/mediaobject.cpp http://commits.kde.org/phonon-gstreamer/002b786f97d8e274691d78355e35f603c78c5963 *** Bug 306676 has been marked as a duplicate of this bug. *** |