Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc version 4.1.2 (Gentoo 4.1.2 p1.0.1) OS: Linux current KDE 4 code crashes every here and there ... each time drkonqi pops-up and, in my case, it always says that the backtrace is invaluable today, I have experienced a crash of krunner (I tried to start konqueror via krunner, krunner crashed right after starting konqueror, if somebody is interested about the circumstances) I immediately went to konsole and attached gdb to the crashed krunner pid (basically, I have used the method from comment #18 to bug 71764) I got: (gdb) backtrace #0 0xb7f41410 in __kernel_vsyscall () #1 0x4e6af576 in pthread_cond_wait () from /lib/libpthread.so.0 #2 0x44283085 in QWaitCondition::wait (this=0x8064ae0, mutex=0x8064acc, time=4294967295) at thread/qwaitcondition_unix.cpp:269 #3 0x44282419 in QThread::wait (this=0x805f150, time=4294967295) at thread/qthread_unix.cpp:552 #4 0x4432c840 in ~QProcessManager (this=0x805f150) at io/qprocess_unix.cpp:261 #5 0x4432b296 in __tcf_0 () at ../../include/QtCore/../../src/corelib/global/qglobal.h:1436 #6 0x4e571d0c in exit () from /lib/libc.so.6 #7 0x4469242b in qt_xio_errhandler () at kernel/qapplication_x11.cpp:553 #8 0xb7c63c81 in KApplication::xioErrhandler (this=0x805f048, dpy=0x805e9b0) at /var/tmp/portage/kde-base/kdelibs-9999.4/work/kdelibs-9999.4/kdeui/kernel/kapplication.cpp:426 #9 0xb7c63cb6 in kde_xio_errhandler (dpy=0x805e9b0) at /var/tmp/portage/kde-base/kdelibs-9999.4/work/kdelibs-9999.4/kdeui/kernel/kapplication.cpp:134 #10 0x4e6f9535 in _XIOError () from /usr/lib/libX11.so.6 #11 0x00000016 in ?? () #12 0xffffffb4 in ?? () #13 0x4e6f94e7 in _XIOError () from /usr/lib/libX11.so.6 #14 0x4e6fa20a in _XRead () from /usr/lib/libX11.so.6 #15 0x0805dc60 in ?? () #16 0xbffb9098 in ?? () #17 0x4e6fa18c in _XRead () from /usr/lib/libX11.so.6 #18 0x4e6fb622 in _XEventsQueued () from /usr/lib/libX11.so.6 #19 0x0824b890 in ?? () #20 0x4e671ff4 in ?? () from /lib/libc.so.6 #21 0x0024b890 in ?? () #22 0x2dc87e15 in ?? () #23 0x0000004d in ?? () #24 0x026000bf in ?? () #25 0x0000004d in ?? () #26 0x00000000 in ?? () this really does not seem invaluable to me, but once again, drkonqi said that: "This backtrace appears to be of no use. This is probably because your packages are built in a way which prevents creation of proper backtraces, or the stack frame was seriously corrupted in the crash." but I am not a developer, so I cannot judge - if the backtrace from gdb posted above is really unusable then please change this bugreport to wish: let drkonqi be more verbose about what to do to produce valuable backtraces since I use Gentoo, I have all the KDE packages, the Qt library and a few other packages compiled with USE flag "debug", CFLAGS including -ggdb and FEATURES "splitdebug" ... I would really like to know, what else do I have to do, and let drkonqi tell me what exactly it does not like about the backtrace (while gdb is able to produce some output - I have to note that unlike the other bugs [#71764, #78985], I got no backtrace from drkonqi at all, just the message quoted above)
I'd like to note that the problem still persist using 4.0.80 (today's svn trunk) ... this time I tried to catch a crash of nspluginviewer: (gdb) backtrace #0 0xb7fe5410 in __kernel_vsyscall () #1 0x4e5d3856 in nanosleep () from /lib/libc.so.6 #2 0x4e5d367b in sleep () from /lib/libc.so.6 #3 0xb7ce0221 in KCrash::startDrKonqi (argv=0xbfda57fc, argc=17) at /var/tmp/portage/kde-base/kdelibs-9999.4/work/kdelibs-9999.4/kdeui/util/kcrash.cpp:366 #4 0xb7ce079c in KCrash::defaultCrashHandler (sig=11) at /var/tmp/portage/kde-base/kdelibs-9999.4/work/kdelibs-9999.4/kdeui/util/kcrash.cpp:287 #5 <signal handler called> #6 0x4823ed46 in XtRemoveTimeOut () from /usr/lib/libXt.so.6 #7 0xb4626000 in ?? () #8 0xbfda5bfb in ?? () #9 0xbfda5bc8 in ?? () #10 0xb5ab7db1 in ?? () from /opt/netscape/plugins/libflashplayer.so Backtrace stopped: previous frame inner to this frame (corrupt stack?) - we see that this time the backtrace is broken (however it still brings one useful information that the crash is flash-related), but, as I said before, it would be nice to know the cause, i.e. that the stack is probably corrupt instead of "built in a way which prevents creation of proper backtraces or ..." p.s. and yes, I would be still interested what else should I do to get nice backtraces?
The part about comment #18 to bug 71764 is INVALID - if gdb cannot create usable backtraces out of the box, that's gdb problem, or distribution problem. The posted backtraces should not be marked as useless though.
DrKonqi processes the given backtrace just fine here. Please run gdb directly from the crashhandler (http://techbase.kde.org/index.php?title=Development/FAQs/Debugging_FAQ#How_do_I_switch_Dr_Konqi_to_developer_mode.3F) and attach the full gdb output here.
ok, so I have tried ... after the crash, at first I've clicked "Show details" and it says: Application: nspluginviewer (nspluginviewer), signal SIGSEGV [?1034hUsing host libthread_db library "/lib/libthread_db.so.1". 0xb7f0f410 in __kernel_vsyscall () [Current thread is 0 (process 26336)] then I clicked "Ladící program" (er, "Debugger") and it showed konsole with gdb, after a ton of messages I got: ... Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 0xb7f0f410 in __kernel_vsyscall () (gdb) backtrace #0 0xb7f0f410 in __kernel_vsyscall () #1 0x4e5d3856 in nanosleep () from /lib/libc.so.6 #2 0x4e5d367b in sleep () from /lib/libc.so.6 #3 0xb7c0a101 in KCrash::startDrKonqi (argv=0xbfb9b71c, argc=17) at /var/tmp/portage/kde-base/kdelibs-9999.4/work/kdelibs-9999.4/kdeui/util/kcrash.cpp:366 #4 0xb7c0a67c in KCrash::defaultCrashHandler (sig=11) at /var/tmp/portage/kde-base/kdelibs-9999.4/work/kdelibs-9999.4/kdeui/util/kcrash.cpp:287 #5 <signal handler called> #6 0x4823ed46 in XtRemoveTimeOut () from /usr/lib/libXt.so.6 #7 0xb4550000 in ?? () #8 0xbfb9bb1b in ?? () #9 0xbfb9bae8 in ?? () #10 0xb59e1db1 in ?? () from /opt/netscape/plugins/libflashplayer.so Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) - so basically the same as running gdb manually
now I have a better example - no question marks :) drkonqi "details": Application: Konsole (konsole), signal SIGSEGV [?1034hUsing host libthread_db library "/lib/libthread_db.so.1". 0xb7f7f410 in __kernel_vsyscall () [Current thread is 0 (process 22163)] versus gdb: (gdb) backtrace #0 0xb7f7f410 in __kernel_vsyscall () #1 0x4e5d3856 in nanosleep () from /lib/libc.so.6 #2 0x4e5d367b in sleep () from /lib/libc.so.6 #3 0xb7994101 in KCrash::startDrKonqi (argv=0xbfac3aec, argc=15) at /var/tmp/portage/kde-base/kdelibs-9999.4/work/kdelibs-9999.4/kdeui/util/kcrash.cpp:366 #4 0xb799467c in KCrash::defaultCrashHandler (sig=11) at /var/tmp/portage/kde-base/kdelibs-9999.4/work/kdelibs-9999.4/kdeui/util/kcrash.cpp:287 #5 <signal handler called> #6 0x4b93f72e in QWidgetPrivate::create_sys (this=<value optimized out>, window=<value optimized out>, initializeWindow=<value optimized out>, destroyOldWindow=<value optimized out>) at kernel/qwidget_x11.cpp:434 #7 0x4b910ff8 in QWidget::create (this=<value optimized out>, window=<value optimized out>, initializeWindow=<value optimized out>, destroyOldWindow=<value optimized out>) at kernel/qwidget.cpp:1093 #8 0x4b9120da in QWidgetPrivate::createRecursively ( this=<value optimized out>) at kernel/qwidget.cpp:1026 #9 0x4b912c73 in QWidget::setVisible (this=<value optimized out>, visible=<value optimized out>) at kernel/qwidget.cpp:5545 #10 0x4b8faa0f in QStackedLayout::setCurrentIndex ( this=<value optimized out>, index=<value optimized out>) at ../../include/QtGui/../../src/gui/kernel/qwidget.h:448 #11 0x4b8fab6d in QStackedLayout::setCurrentWidget ( this=<value optimized out>, widget=<value optimized out>) at kernel/qstackedlayout.cpp:360 #12 0x4bca9b4a in QStackedWidget::setCurrentWidget ( this=<value optimized out>, widget=<value optimized out>) at widgets/qstackedwidget.cpp:242 #13 0xb7f54096 in Konsole::TabbedViewContainerV2::setActiveView ( this=0x81a7bf8, view=0x816f618) at /var/tmp/portage/kde-base/kdebase-9999.4/work/kdebase-9999.4/apps/konsole/src/ViewContainer.cpp:622 #14 0xb7f534a6 in Konsole::ViewContainer::activatePreviousView ( this=0x81a7bf8) ---Type <return> to continue, or q <return> to quit--- at /var/tmp/portage/kde-base/kdebase-9999.4/work/kdebase-9999.4/apps/konsole/src/ViewContainer.cpp:217 #15 0xb7f59116 in Konsole::ViewManager::previousView (this=0x8164ab8) at /var/tmp/portage/kde-base/kdebase-9999.4/work/kdebase-9999.4/apps/konsole/src/ViewManager.cpp:267 #16 0xb7f5d85a in Konsole::ViewManager::sessionFinished (this=0x8164ab8) at /var/tmp/portage/kde-base/kdebase-9999.4/work/kdebase-9999.4/apps/konsole/src/ViewManager.cpp:311 #17 0xb7f5da39 in Konsole::ViewManager::qt_metacall (this=0x8164ab8, _c=QMetaObject::InvokeMetaMethod, _id=15, _a=0xbfac47a4) at /var/tmp/portage/kde-base/kdebase-9999.4/work/kdebase_build/apps/konsole/src/ViewManager.moc:128 #18 0x4ab22f75 in QMetaObject::activate (sender=<value optimized out>, from_signal_index=<value optimized out>, to_signal_index=<value optimized out>, argv=<value optimized out>) at kernel/qobject.cpp:3081 #19 0x4ab23af2 in QMetaObject::activate (sender=<value optimized out>, m=<value optimized out>, local_signal_index=<value optimized out>, argv=Could not find the frame base for "QMetaObject::activate(QObject*, QMetaObject const*, int, void**)". ) at kernel/qobject.cpp:3140 #20 0xb7f2e845 in Konsole::Session::finished (this=0x82f5468) at /var/tmp/portage/kde-base/kdebase-9999.4/work/kdebase_build/apps/konsole/src/Session.moc:197 #21 0xb7f3335b in Konsole::Session::done (this=0x82f5468, exitStatus=0) at /var/tmp/portage/kde-base/kdebase-9999.4/work/kdebase-9999.4/apps/konsole/src/Session.cpp:618 #22 0xb7f337fa in Konsole::Session::qt_metacall (this=0x82f5468, _c=QMetaObject::InvokeMetaMethod, _id=17, _a=0xbfac4da8) at /var/tmp/portage/kde-base/kdebase-9999.4/work/kdebase_build/apps/konsole/src/Session.moc:139 #23 0x4ab22f75 in QMetaObject::activate (sender=<value optimized out>, from_signal_index=<value optimized out>, to_signal_index=<value optimized out>, argv=<value optimized out>) at kernel/qobject.cpp:3081 #24 0x4ab23af2 in QMetaObject::activate (sender=<value optimized out>, m=<value optimized out>, local_signal_index=<value optimized out>, argv=Could not find the frame base for "QMetaObject::activate(QObject*, QMetaObject const*, int, void**)". ---Type <return> to continue, or q <return> to quit--- ) at kernel/qobject.cpp:3140 #25 0x4aab1439 in QProcess::finished (this=Could not find the frame base for"QProcess::finished(int, QProcess::ExitStatus)". ) at .moc/debug-shared/moc_qprocess.cpp:133 #26 0x4aab2f4f in QProcessPrivate::_q_processDied ( this=<value optimized out>) at io/qprocess.cpp:672 #27 0x4aaf3c2d in QProcessPrivate::waitForFinished ( this=<value optimized out>, msecs=<value optimized out>) at io/qprocess_unix.cpp:1153 #28 0x4aab1d8c in QProcess::waitForFinished (this=<value optimized out>, msecs=<value optimized out>) at io/qprocess.cpp:1290 #29 0xb7f2efee in Konsole::Session::kill (this=0x82f5468, signal=1) at /var/tmp/portage/kde-base/kdebase-9999.4/work/kdebase-9999.4/apps/konsole/src/Session.cpp:557 #30 0xb7f2f0ae in Konsole::Session::close (this=0x82f5468) at /var/tmp/portage/kde-base/kdebase-9999.4/work/kdebase-9999.4/apps/konsole/src/Session.cpp:568 #31 0xb7f42c14 in ~SessionManager (this=0x8168338) at /var/tmp/portage/kde-base/kdebase-9999.4/work/kdebase-9999.4/apps/konsole/src/SessionManager.cpp:201 #32 0xb7f3e092 in destroy () at /var/tmp/portage/kde-base/kdebase-9999.4/work/kdebase-9999.4/apps/konsole/src/SessionManager.cpp:725 #33 0xb7f3e035 in __tcf_0 () at /usr/kde/svn/include/kglobal.h:65 #34 0x4e571d0c in exit () from /lib/libc.so.6 #35 0x4e55bfe4 in __libc_start_main () from /lib/libc.so.6 #36 0x08048711 in _start () (gdb)
Created attachment 23269 [details] kdebase/runtime/drkonqi patch And "[Current thread is 0 (process 22163)]" is the last thing it says? Since you've compiled from sources, could you apply this patch and, after reproducing the problem again, attach file /tmp/dbg.txt that this patch creates?
yes, it is really the last thing ... just like now: Application: nspluginviewer (nspluginviewer), signal SIGSEGV [?1034hUsing host libthread_db library "/lib/libthread_db.so.1". 0xb7fc6410 in __kernel_vsyscall () [Current thread is 0 (process 23075)] and once again our familiar gdb backtrace: (gdb) backtrace #0 0xb7fc6410 in __kernel_vsyscall () #1 0x4e5d3856 in nanosleep () from /lib/libc.so.6 #2 0x4e5d367b in sleep () from /lib/libc.so.6 #3 0x4131ce01 in KCrash::startDrKonqi (argv=Could not find the frame base for "KCrash::startDrKonqi(char const**, int)". ) at /var/tmp/portage/kde-base/kdelibs-9999.4/work/kdelibs-9999.4/kdeui/util/kcrash.cpp:366 #4 0x4131d37c in KCrash::defaultCrashHandler (sig=<value optimized out>) at /var/tmp/portage/kde-base/kdelibs-9999.4/work/kdelibs-9999.4/kdeui/util/kcrash.cpp:287 #5 <signal handler called> #6 0x4823ed46 in XtRemoveTimeOut () from /usr/lib/libXt.so.6 #7 0xb4dae000 in ?? () #8 0xbf88dbdb in ?? () #9 0xbf88dba8 in ?? () #10 0xb623fdb1 in ?? () from /opt/netscape/plugins/libflashplayer.so Backtrace stopped: previous frame inner to this frame (corrupt stack?) /tmp/dbg.txt: Using host libthread_db library "/lib/libthread_db.so.1". 0xb7fc6410 in __kernel_vsyscall () [Current thread is 0 (process 23075)] EXIT:0:0
Looks like gdb bug to me. And the commands used by drkonqi are actually "thread" and "thread apply all bt" - do those work in manually launched gdb?
nope, this does not work: (gdb) thread [Current thread is 0 (process 26944)] (gdb) thread apply all bt (gdb) if I try normal 'bt' ... well, is it worth to post it again? :-) if this is a bug of gdb - # gdb --version GNU gdb 6.7.1 Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". - then a) can drkonqui try another commands that work to get some meaningful results? b) can drkonqui report known broken gdb versions to user so that he knows what is the problem and can take appropriate action (i.e. upgrade gdb)?
I think we have enough of our own bugs to fix (at least I read so somewhere). Also, while this is just a guess, I would say that the actual problem is that your Gentoo is a bit over-optimized and libpthread/libthread_db are stripped, rendering gdb's thread support non-functional (gdb usually says something like "[Thread debugging using libthread_db enabled]").
Created attachment 23364 [details] gdb console log with glibc stripped
Created attachment 23365 [details] gdb console log with glibc including debuginfo
> I think we have enough of our own bugs to fix > (at least I read so somewhere). closing a bug will magically make it go away? btw, I guess resolving this bug would actually help fixing the others since you would get more informations > I would say that the actual problem is that your Gentoo > is a bit over-optimized and libpthread/libthread_db are stripped stripping is "over optimizing"? - wov, so, Fedora is over-optimized, Mandriva is over-optimized, even Debian is over-optimized ... I am reopening the bug: in comment #2 you say "The posted backtraces should not be marked as useless though." - so, if there is a way to get an useful backtrace but drkonqi fails to do so, it's drkonqi's fault compare the attached console logs - I do not see anything important in the second one which is not present in the first (however, I can be mistaken, I'm not a programmer ...) I add the corresponding drkonqi output for the second case (after adding debug symbols for glibc): Application: nspluginviewer (nspluginviewer), signal SIGSEGV [?1034hUsing host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 0xb7d8a6d0 (LWP 17904)] [New Thread 0xb3b9ab90 (LWP 17910)] [New Thread 0xb439bb90 (LWP 17909)] [New Thread 0xb4b9cb90 (LWP 17908)] [KCrash handler] #6 0x4823ed46 in XtRemoveTimeOut () from /usr/lib/libXt.so.6 #7 0xb4ba1000 in ?? () #8 0xbff0ea6b in ?? () #9 0xbff0ea38 in ?? () #10 0xb6032db1 in ?? () from /opt/netscape/plugins/libflashplayer.so Backtrace stopped: previous frame inner to this frame (corrupt stack?) #0 0xb7f49410 in __kernel_vsyscall () KDE does not exist in "vacuum" - if it is using external tools, it has to be able to cope with any of their possible problems ... you can never ever rely on the assumption that the things work as expected; for example, if somebody writes code for opening a file, a check whether the operation went ok (so that the program does not crash on using a null handle) is a must and I bet you wouldn't argue, but now you say you just issue a command and expect it not to fail without checking any preconditions? I just looked into kdebase/README and kdebase/runtime/drkonqi/README and there is not a single note about needing glibc debuginfo - so regarding comment #2, it's a packagers fault that he has not a crystall ball to tell him that he has to make drkonqi depending on it? p.s. sorry for writing in a bit ironical style - I cannot help it to express myself better; I do not want to harm anybody, and I appreciate the work put into KDE and the fact that we discovered the cause of the problem ... now I just would like to make sure that no one runs into it in the future; if there is too much other (more important) work then just postpone the solution but do not say that the problem does not exist
The important difference between the two attachments is that in one 'thread apply all bt' works, while in the other one it doesn't, so they only prove that this is not a KDE problem. And we do not fix gdb problems, sorry. I suggest you report to your distribution or gdb developers. They should know better why gdb needs it this way (and it doesn't need debuginfo as such, but it's only limited to the two libraries I mentioned, AFAIK - gdb works fine in this regard on openSUSE even without any debuginfo). As far as working around other bugs, that's a bonus and it depends on many factors. If you think it's so easy, you're welcome to contribute a patch. We're currently way too busy fixing our own bugs.