Application: dolphin (4.13.97) KDE Platform Version: 4.13.97 Qt Version: 4.8.6 Operating System: Linux 3.13.0-32-generic x86_64 Distribution: Ubuntu 14.04.1 LTS -- Information about the crash: - What I was doing when the application crashed: Just did a 200 package upgrade (KDE backports) using muon. Crash occurred before upgrade was completed. - Unusual behavior I noticed: Firefox appeared in my taskbar. It's on another desktop and should not have displayed. I clecked on it and didn't see that it had done anything and then clicked back to the upgrade. -- Backtrace: Application: Dolphin (dolphin), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7fdeb17fa7c0 (LWP 2520))] Thread 4 (Thread 0x7fde942c5700 (LWP 2586)): #0 0x00007fdeb10bd03d in poll () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007fdea8313fe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007fdea83140ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007fdead12b7be in QEventDispatcherGlib::processEvents (this=0x7fde8c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:436 #4 0x00007fdead0fd0af in QEventLoop::processEvents (this=this@entry=0x7fde942c4de0, flags=...) at kernel/qeventloop.cpp:149 #5 0x00007fdead0fd3a5 in QEventLoop::exec (this=this@entry=0x7fde942c4de0, flags=...) at kernel/qeventloop.cpp:204 #6 0x00007fdeacff9c5f in QThread::exec (this=this@entry=0x25a1c90) at thread/qthread.cpp:537 #7 0x00007fdead0de823 in QInotifyFileSystemWatcherEngine::run (this=0x25a1c90) at io/qfilesystemwatcher_inotify.cpp:265 #8 0x00007fdeacffc32f in QThreadPrivate::start (arg=0x25a1c90) at thread/qthread_unix.cpp:349 #9 0x00007fdea87f3182 in start_thread (arg=0x7fde942c5700) at pthread_create.c:312 #10 0x00007fdeb10ca38d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 3 (Thread 0x7fde939bc700 (LWP 2601)): #0 0x00007fdeb10d7f8b in pthread_mutex_unlock (mutex=0x7fde84000a60) at forward.c:194 #1 0x00007fdea83559c1 in g_mutex_unlock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007fdea8313718 in g_main_context_prepare () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007fdea8313f03 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x00007fdea83140ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x00007fdead12b7be in QEventDispatcherGlib::processEvents (this=0x7fde840008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:436 #6 0x00007fdead0fd0af in QEventLoop::processEvents (this=this@entry=0x7fde939bbe20, flags=...) at kernel/qeventloop.cpp:149 #7 0x00007fdead0fd3a5 in QEventLoop::exec (this=this@entry=0x7fde939bbe20, flags=...) at kernel/qeventloop.cpp:204 #8 0x00007fdeacff9c5f in QThread::exec (this=<optimized out>) at thread/qthread.cpp:537 #9 0x00007fdeacffc32f in QThreadPrivate::start (arg=0x274ae90) at thread/qthread_unix.cpp:349 #10 0x00007fdea87f3182 in start_thread (arg=0x7fde939bc700) at pthread_create.c:312 #11 0x00007fdeb10ca38d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 2 (Thread 0x7fde92b43700 (LWP 2602)): #0 0x00007fdeb10bb73d in read () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007fdea8354c20 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007fdea8313b14 in g_main_context_check () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007fdea8313f7b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x00007fdea83140ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x00007fdead12b7be in QEventDispatcherGlib::processEvents (this=0x7fde880008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:436 #6 0x00007fdead0fd0af in QEventLoop::processEvents (this=this@entry=0x7fde92b42de0, flags=...) at kernel/qeventloop.cpp:149 #7 0x00007fdead0fd3a5 in QEventLoop::exec (this=this@entry=0x7fde92b42de0, flags=...) at kernel/qeventloop.cpp:204 #8 0x00007fdeacff9c5f in QThread::exec (this=this@entry=0x276f700) at thread/qthread.cpp:537 #9 0x00007fdead0de823 in QInotifyFileSystemWatcherEngine::run (this=0x276f700) at io/qfilesystemwatcher_inotify.cpp:265 #10 0x00007fdeacffc32f in QThreadPrivate::start (arg=0x276f700) at thread/qthread_unix.cpp:349 #11 0x00007fdea87f3182 in start_thread (arg=0x7fde92b43700) at pthread_create.c:312 #12 0x00007fdeb10ca38d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 1 (Thread 0x7fdeb17fa7c0 (LWP 2520)): [KCrash Handler] #6 DolphinViewContainer::setActive (this=0x0, active=true) at ../../../dolphin/src/dolphinviewcontainer.cpp:200 #7 0x00007fdeb13e3a48 in DolphinTabPage::restoreState (this=0x2446860, state=...) at ../../../dolphin/src/dolphintabpage.cpp:218 #8 0x00007fdeb13d608e in DolphinMainWindow::readProperties (this=0x2265ff0, group=...) at ../../../dolphin/src/dolphinmainwindow.cpp:588 #9 0x00007fdeae8ae510 in KMainWindow::readPropertiesInternal (this=this@entry=0x2265ff0, config=0x27d5450, number=number@entry=1) at ../../kdeui/widgets/kmainwindow.cpp:739 #10 0x00007fdeae8ae69a in KMainWindow::restore (this=0x2265ff0, number=number@entry=1, show=show@entry=true) at ../../kdeui/widgets/kmainwindow.cpp:539 #11 0x00007fdeb13d133c in DolphinApplication::restoreSession (this=this@entry=0x7fff640a8f50) at ../../../dolphin/src/dolphinapplication.cpp:100 #12 0x00007fdeb13e5272 in kdemain (argc=3, argv=0x7fff640a9088) at ../../../dolphin/src/main.cpp:91 #13 0x00007fdeb0ff0ec5 in __libc_start_main (main=0x4006d0 <main(int, char**)>, argc=3, argv=0x7fff640a9088, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff640a9078) at libc-start.c:287 #14 0x00000000004006fe in _start () Report to https://bugs.kde.org/
Thanks for the bug report! According to the backtrace, Dolphin tried to restore a saved session when the crash happened. The format in which the information about saved sessions is saved has changed between 4.13 and 4.14. Unfortunately, it seems that this can cause a crash if Dolphin 4.14 tries to load a data file that has been stored by Dolphin 4.13. It might be too late to add some code that checks if data in the old format is available and reads it properly (4.14.0 is tagged in only two days), but maybe we can at least fix the crash. I think that checking if the QByteArray that stores a tab's state is empty and simply not doing anything in that case should be sufficient (the current code unfortunately does somehting that causes a crash then because everything, including the m_primaryViewActive variable, is initalized to false if the QByteArray is empty, and the 'else' branch of the "if (m_primaryViewActive)" statement tries to access m_primaryViewContainer, which is null because the local variable "isSplitViewEnabled" in DolphinTabPage::restoreState(const QByteArray& state) is also false).
Git commit cb04f335cbe1b9b2bdbd754a77a4335f8e605e06 by Frank Reininghaus. Committed on 12/08/2014 at 07:08. Pushed by freininghaus into branch 'KDE/4.14'. Fix crash when restoring a session stored with Dolphin 4.13 or earlier Since DolphinTabPage::saveState() and DolphinTabPage::restoreState(const QByteArray& state) save and restore the state of each tab in a different format than DolphinMainWindow did before the refactoring, we can run into problems: the first time a user logs into a session that has Dolphin 4.14, Dolphin might read session data that does not contain the QByteArray that DolphinTabPage wants to read the data from. In restoreState, isSplitViewEnabled will thus have the value false, and no secondary view will be created. Later on, m_primaryViewActive will also be set to false, but the else branch of the following "if (m_primaryViewActive)" then tries to activate the secondary view, which does not exist -> we get a crash. The easiest solution is to not restore the tab state if no session data in the new format is found. REVIEW: 119718 FIXED-IN: 4.14.0 M +4 -0 dolphin/src/dolphintabpage.cpp http://commits.kde.org/kde-baseapps/cb04f335cbe1b9b2bdbd754a77a4335f8e605e06
Glad it helped. I have tried to submit crash reports many times in the past. This is the first time the install packages for debugging option actually worked. I still had to file it manually because I got my password wrong and there was no way to reenter it. I even logged on to the bugs website in another browser tab. On 08/11/2014 07:11 AM, Frank Reininghaus wrote: > https://bugs.kde.org/show_bug.cgi?id=338187 > > Frank Reininghaus <frank78ac@googlemail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Keywords| |investigated, regression > Ever confirmed|0 |1 > Severity|normal |crash > Status|UNCONFIRMED |CONFIRMED > > --- Comment #1 from Frank Reininghaus <frank78ac@googlemail.com> --- > Thanks for the bug report! > > According to the backtrace, Dolphin tried to restore a saved session when the > crash happened. The format in which the information about saved sessions is > saved has changed between 4.13 and 4.14. Unfortunately, it seems that this can > cause a crash if Dolphin 4.14 tries to load a data file that has been stored by > Dolphin 4.13. > > It might be too late to add some code that checks if data in the old format is > available and reads it properly (4.14.0 is tagged in only two days), but maybe > we can at least fix the crash. > > I think that checking if the QByteArray that stores a tab's state is empty and > simply not doing anything in that case should be sufficient (the current code > unfortunately does somehting that causes a crash then because everything, > including the m_primaryViewActive variable, is initalized to false if the > QByteArray is empty, and the 'else' branch of the "if (m_primaryViewActive)" > statement tries to access m_primaryViewContainer, which is null because the > local variable "isSplitViewEnabled" in DolphinTabPage::restoreState(const > QByteArray& state) is also false). >