Application: digikam (2.9.0) KDE Platform Version: 4.9.3 Qt Version: 4.8.3 Operating System: Linux 3.6.6-3.fc18.x86_64 x86_64 Distribution: "Fedora release 18 (Spherical Cow)" -- Information about the crash: Digikam crashes on startup The crash can be reproduced every time. -- Backtrace: Application: digiKam (digikam), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". 81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) [Current thread is 1 (Thread 0x7f76d9ec4a80 (LWP 24568))] Thread 5 (Thread 0x7f76cc942700 (LWP 24569)): #0 g_mutex_get_impl (mutex=0x21418d0) at gthread-posix.c:132 #1 0x00007f76d8fafd99 in g_mutex_lock (mutex=mutex@entry=0x21418d0) at gthread-posix.c:210 #2 0x00007f76d8f725e3 in g_main_context_prepare (context=context@entry=0x21418d0, priority=priority@entry=0x7f76cc941a28) at gmain.c:2988 #3 0x00007f76d8f72c6b in g_main_context_iterate (context=0x21418d0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3270 #4 0x00007f76d8f731a2 in g_main_loop_run (loop=0x2141860) at gmain.c:3484 #5 0x00007f76d8226546 in gdbus_shared_thread_func (user_data=0x21418a0) at gdbusprivate.c:277 #6 0x00007f76d8f965f5 in g_thread_proxy (data=0x213cb70) at gthread.c:797 #7 0x0000003ed2caa764 in ?? () from /usr/lib64/nvidia/libGL.so.1 #8 0x00007f76d981dd15 in start_thread (arg=0x7f76cc942700) at pthread_create.c:308 #9 0x00007f76d95502cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114 Thread 4 (Thread 0x7f76bffff700 (LWP 24572)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:165 #1 0x0000003ed147bd2b in wait (time=18446744073709551615, this=0x22813f0) at thread/qwaitcondition_unix.cpp:86 #2 QWaitCondition::wait (this=<optimized out>, mutex=0x22812e8, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:158 #3 0x00000000005c88f8 in Digikam::ScanController::run (this=0x2281080) at /usr/src/debug/digikam-2.9.0/core/digikam/database/scancontroller.cpp:698 #4 0x0000003ed147b7cc in QThreadPrivate::start (arg=0x2281080) at thread/qthread_unix.cpp:338 #5 0x0000003ed2caa764 in ?? () from /usr/lib64/nvidia/libGL.so.1 #6 0x00007f76d981dd15 in start_thread (arg=0x7f76bffff700) at pthread_create.c:308 #7 0x00007f76d95502cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114 Thread 3 (Thread 0x7f76bf7fe700 (LWP 24573)): #0 0x00007f76d954354d in read () at ../sysdeps/unix/syscall-template.S:81 #1 0x0000003ed2ca974c in ?? () from /usr/lib64/nvidia/libGL.so.1 #2 0x0000003ed5801be7 in ?? () from /usr/lib64/nvidia/tls/libnvidia-tls.so.304.64 #3 0x00007f76d8faf0df in read (__nbytes=16, __buf=0x7f76bf7fd820, __fd=<optimized out>) at /usr/include/bits/unistd.h:44 #4 g_wakeup_acknowledge (wakeup=0x7f76b8001da0) at gwakeup.c:212 #5 0x00007f76d8f728d4 in g_main_context_check (context=context@entry=0x7f76b00009d0, max_priority=2147483647, fds=fds@entry=0x7f76b0002c30, n_fds=n_fds@entry=1) at gmain.c:3129 #6 0x00007f76d8f72ce2 in g_main_context_iterate (context=context@entry=0x7f76b00009d0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3287 #7 0x00007f76d8f72e64 in g_main_context_iteration (context=0x7f76b00009d0, may_block=1) at gmain.c:3351 #8 0x0000003ed15a6176 in QEventDispatcherGlib::processEvents (this=0x7f76b00008f0, flags=...) at kernel/qeventdispatcher_glib.cpp:426 #9 0x0000003ed1576e2f in QEventLoop::processEvents (this=this@entry=0x7f76bf7fda10, flags=...) at kernel/qeventloop.cpp:149 #10 0x0000003ed15770b8 in QEventLoop::exec (this=0x7f76bf7fda10, flags=...) at kernel/qeventloop.cpp:204 #11 0x0000003ed14787f0 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:501 #12 0x0000003ed155763f in QInotifyFileSystemWatcherEngine::run (this=0x2284760) at io/qfilesystemwatcher_inotify.cpp:248 #13 0x0000003ed147b7cc in QThreadPrivate::start (arg=0x2284760) at thread/qthread_unix.cpp:338 #14 0x0000003ed2caa764 in ?? () from /usr/lib64/nvidia/libGL.so.1 #15 0x00007f76d981dd15 in start_thread (arg=0x7f76bf7fe700) at pthread_create.c:308 #16 0x00007f76d95502cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114 Thread 2 (Thread 0x7f76beffd700 (LWP 24622)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:165 #1 0x0000003ed147bd2b in wait (time=18446744073709551615, this=0x7ff7dc0) at thread/qwaitcondition_unix.cpp:86 #2 QWaitCondition::wait (this=<optimized out>, mutex=0x7ff61a8, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:158 #3 0x0000003eee9357f9 in Digikam::ParkingThread::run (this=0x7ff6190) at /usr/src/debug/digikam-2.9.0/core/libs/threads/threadmanager.cpp:119 #4 0x0000003ed147b7cc in QThreadPrivate::start (arg=0x7ff6190) at thread/qthread_unix.cpp:338 #5 0x0000003ed2caa764 in ?? () from /usr/lib64/nvidia/libGL.so.1 #6 0x00007f76d981dd15 in start_thread (arg=0x7f76beffd700) at pthread_create.c:308 #7 0x00007f76d95502cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:114 Thread 1 (Thread 0x7f76d9ec4a80 (LWP 24568)): [KCrash Handler] #6 0x00007f76bd47f38b in Phonon::Gstreamer::Pipeline::isSeekable (this=0x0) at /usr/src/debug/phonon-backend-gstreamer-4.6.2/gstreamer/pipeline.cpp:771 #7 0x0000003ee32555f1 in Phonon::SeekSliderPrivate::_k_stateChanged (this=this@entry=0x82c9a40, newstate=Phonon::StoppedState) at /usr/src/debug/phonon-4.6.0/phonon/seekslider.cpp:160 #8 0x0000003ee32557d9 in Phonon::SeekSlider::setMediaObject (this=0x82c6b30, media=0x8584400) at /usr/src/debug/phonon-4.6.0/phonon/seekslider.cpp:81 #9 0x00000000006528e0 in Digikam::MediaPlayerView::MediaPlayerView (this=0x82c4260, parent=0x2443240) at /usr/src/debug/digikam-2.9.0/core/digikam/views/mediaplayerview.cpp:169 #10 0x0000000000648229 in Digikam::StackedView::StackedView (this=0x2443240, parent=<optimized out>) at /usr/src/debug/digikam-2.9.0/core/digikam/views/stackedview.cpp:111 #11 0x000000000064e937 in Digikam::DigikamView::DigikamView (this=0x2400960, parent=0x23c14b0, modelCollection=0x7ff9a80) at /usr/src/debug/digikam-2.9.0/core/digikam/views/digikamview.cpp:207 #12 0x000000000057362a in Digikam::DigikamApp::setupView (this=this@entry=0x23c14b0) at /usr/src/debug/digikam-2.9.0/core/digikam/main/digikamapp.cpp:520 #13 0x000000000058b069 in Digikam::DigikamApp::DigikamApp (this=0x23c14b0, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at /usr/src/debug/digikam-2.9.0/core/digikam/main/digikamapp.cpp:258 #14 0x00000000004906e3 in main (argc=1, argv=0x7fff0c76a608) at /usr/src/debug/digikam-2.9.0/core/digikam/main/main.cpp:188 Reported using DrKonqi
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. ***