| Summary: | crashes almost randomly using konqueror | ||
|---|---|---|---|
| Product: | [Unmaintained] kdelibs | Reporter: | Hannes H <bugzilla> |
| Component: | klauncher | Assignee: | kdelibs bugs <kdelibs-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | cfeck, kde, mpyne |
| Priority: | NOR | ||
| Version: | 4.1 | ||
| Target Milestone: | --- | ||
| Platform: | FreeBSD Ports | ||
| OS: | FreeBSD | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
I wasn't precise on the error-messages, here's what I get when I want to open a new tab: "The requested operation could not be completed Cannot Initiate the about Protocol Technical Reason: Unable to Launch Process Details of the Request: URL: about:blank Protocol: about Date and Time: Thursday, 2. October 2008 14:36 Additional Information: Cannot talk to klauncher: Connection is closed" ps aux tells me klauncher was just restarted... Hi, I've seen the same problem with Kubuntu 8.10 (KDE 4.1.2), and I can reproduce it by: 1) Login. 2) Start a konqueror. 3) Enable "open as tab in existing Konqueror when URL is called externally" 4) Change to a different desktop that doesn't have a konqueror window, and run kfmclient openURL "http://www.kde.org" This generates a "konqueror crashed, would you like to restore the session" message, and after choosing an option in that, a new konqueror window appears. At this point the old konqueror window cannot talk to the klauncher process anymore. I am glad I am not the only one! I also use "open as tab in existing Konqueror when URL is called externally". I can reliably reproduce it the way you mentioned. Using the steps from comment #2, I cannot reproduce this bug with current trunk. The behaviour is that it opens in existing browser window, when you are on the same desktop, but opens a new window, when you are on a different desktop when calling the kfmclient. So the problem may be BSD specific, but I cannot test this. Please try to reproduce with a recent KDE, thanks. I cannot reproduce the bug anymore. As far as I am concerned, this PR may be closed. Thanks. Closing as the reporter indicates the issue appears to be resolved. |
Version: (using KDE 4.1.1) OS: FreeBSD Installed from: FreeBSD Ports Once in a while Konqueror on Filebrowser mode tells me that it lost connection to klauncher or in Webbrowser mode it tells me that it cannot initiate its foo-kio-slave, because it cannot contact klauncher. This Konqueror-session is than completely useless and has to be closed, however other Konqueror sessions are not effected. Also I have realized that often (not always) this behaviour seems to follow immediately after starting a new Konqueror session, i.e. SessionA is open, I go to to a different virtual Desktop and open SessionB => SessionA loses its klauncher. Apperently klauncher crashes in the background (see below). The issue happens rather often (once in an hour at least), I have had it since 4.1.0, but it seems to be happening more often of late (although that might just be perception). Since Konqueror is rather slow on FreeBSD vs Linux, problems communicating with klauncher could be related. Thank you very much! Heres the backtrace on ~/klauncher.core (dont know if its useful): #0 0x29a16067 in kill () from /lib/libc.so.7 #1 0x28d14127 in raise () from /lib/libthr.so.3 #2 0x28584e4b in KCompletionBasePrivate (this=0xb) at /work/a/ports/x11/kdelibs4/work/kdelibs-4.1.1/kdeui/util/kcompletionbase.cpp:32 #3 <signal handler called> #4 0x28c77c9d in QMetaObject::connect () from /usr/local/lib/qt4/libQtCore.so.4 #5 0x28c7ab98 in QObject::connect () from /usr/local/lib/qt4/libQtCore.so.4 #6 0x2808ac27 in KLauncher::acceptSlave (this=0x8142160) at /work/a/ports/x11/kdelibs4/work/kdelibs-4.1.1/kinit/klauncher.cpp:1116 #7 0x2808ada4 in KLauncher::qt_metacall (this=0x8142160, _c=QMetaObject::InvokeMetaMethod, _id=9, _a=0xbfbfe108) at klauncher.moc:153 #8 0x28c79a8c in QMetaObject::activate () from /usr/local/lib/qt4/libQtCore.so.4 #9 0x28c79ec2 in QMetaObject::activate () from /usr/local/lib/qt4/libQtCore.so.4 #10 0x2811fd17 in KIO::ConnectionServer::isListening (this=0x8142190) at /work/a/ports/x11/kdelibs4/work/kdelibs-4.1.1/kio/kio/connection.cpp:577 #11 0x2811fea3 in KIO::AbstractConnectionBackend::newConnection (this=0x8142190) at connection_p.moc:94 #12 0x28c79a8c in QMetaObject::activate () from /usr/local/lib/qt4/libQtCore.so.4 #13 0x28c79ec2 in QMetaObject::activate () from /usr/local/lib/qt4/libQtCore.so.4 #14 0x2811fd97 in KIO::Connection::metaObject (this=0x282ea740) at connection.moc:51 #15 0x08160460 in ?? () #16 0x282ea740 in ?? () #17 0x00000002 in ?? () #18 0x00000000 in ?? () #19 0x2811fd69 in KIO::AbstractConnectionBackend::metaObject () at connection_p.moc:52 #20 0x2834d4a8 in ?? () from /usr/local/kde4/lib/libkio.so.7 #21 0xbfbfe278 in ?? () #22 0x2811ff45 in KIO::SocketConnectionBackend::socketDisconnected (this=0x8160460) at /work/a/ports/x11/kdelibs4/work/kdelibs-4.1.1/kio/kio/connection.cpp:192 Previous frame identical to this frame (corrupt stack?)