Version: 4.0-8.1 (using KDE 4.0.0) Installed from: SuSE RPMs The application don't crash but is frozen and takes 100% of the cpu, the only solution is to clese or kill the application if you call konqueror form a konsole, it works fine I don't know how to view how is the menu defined, so i can't notice any difference in how it is being called Conclusion. konqueror is unusable if called from the menu
Confirm this issue except crash. Konqueror start very slowly, but start anyway and start welcome page displayed forged without any images. The start from konsole works fine. the menu command is kfmclient openProfile webbrowsing
Created attachment 23279 [details] console output of "/usr/bin/kfmclient openProfile webbrowsing" Here is console output, then I try to execute menu command from console and terminate frozen konqueror
Confirm. Seeing something like this here, only it's looping on trying to start klauncher and not kbuildsycoca4.. Something is up with the d-bus connection... QDBusConnectionPrivate::connectSignal: received error from D-Bus server while connecting signal to KIO::Scheduler::slotReparseSlaveConfiguration(QString): org.freedesktop.DBus.Error.Disconnected (Connection is closed) konqueror(6016)/kio (KIOConnection) KIO::ConnectionServer::listenForRemote: Listening on "local:/tmp/maksim-kde4/ksocket-maksim/konquerorSa6016.slave-socket" konqueror(6016) KToolInvocation::klauncher: klauncher not running... launching kdeinit <unknown program name>(6018)/ findLibraryInternal: looking for: "./libklauncher" <unknown program name>(6018)/ findLibraryInternal: lib file: "" kdeinit4: preparing to launch /opt/kde4/lib/kde4/libexec/klauncher kdeinit4: Launched KLauncher, pid = 6019 result = 0 klauncher(6019) kdemain: Waiting for already running klauncher to exit. klauncher(6019) kdemain: Waiting for already running klauncher to exit. kdeinit4: PID 6015 terminated. klauncher(6019) kdemain: Another instance of klauncher is already running! kdeinit4: Communication error with launcher. Exiting! konqueror(6016)/kio (KIOConnection) KIO::ConnectionServer::listenForRemote: Listening on "local:/tmp/maksim-kde4/ksocket-maksim/konquerorsc6016.slave-socket" konqueror(6016) KToolInvocation::klauncher: klauncher not running... launching kdeinit <unknown program name>(6021)/ findLibraryInternal: looking for: "./libklauncher" <unknown program name>(6021)/ findLibraryInternal: lib file: "" kdeinit4: preparing to launch /opt/kde4/lib/kde4/libexec/klauncher kdeinit4: Launched KLauncher, pid = 6022 result = 0 klauncher(6022) kdemain: Waiting for already running klauncher to exit. klauncher(6022) kdemain: Waiting for already running klauncher to exit. klauncher(6022) kdemain: Another instance of klauncher is already running! kdeinit4: Communication error with launcher. Exiting!
Question, after consulting w/a guru: which libdbus version do you folks have?
23:00 aragorn:~ # rpm -qa | grep dbus dbus-1-devel-1.0.2-59.2 dbus-1-qt3-0.62-110 kdbus-0.8.6_SVN_20070413-60 dbus-1-1.0.2-59.2 dbus-1-qt3-32bit-0.62-110 libqt4-dbus-1-4.3.3-9.1 dbus-1-glib-0.74-25 libqt4-dbus-1-32bit-4.3.1-23.2 dbus-1-glib-32bit-0.74-25 dbus-1-x11-1.0.2-67 dbus-1-mono-0.63-90 dbus-1-32bit-1.0.2-59.2 dbus-1-qt3-devel-0.62-110 here is my dbus stuff
I can confirm this too, plus after launching from konsole konqueror stops working after a while complaining about klauncher can reached and I can can confirm some dbus errors I can't report here now. dbus 1.0.2-4 dbus-qt3 0.62-3 dbus-glib 0.74-1
Never mind that question, actually. Regression after r764896. QDBus seems to somehow take exception to the objectName (the path is right). If I just do: + q->setObjectName( "foob" ); QDBusConnection::sessionBus().registerObject(dbusName, q, It works.. Might have to look inside QDbus to figure out what's up...
*** Bug 156462 has been marked as a duplicate of this bug. ***
Aha. I think I got it. KonquerorAdaptor::createBrowserWindowFromProfile and similar methods use the window's objectName for the dbus object path. Seems quite ugly. Seli, is there any way of not touching the objectName and still getting the window roles right? r764896 is effectively breaking backwards compat here. I can certainly fix konq (especially if dbusName is made public, which will make this code -much- less hacky), but I am concerned about other potential users.
I too got this issue... the work around I am using was to change the icon application launch to: kfmclient openURL about:blank It appears to happen when using a profile. Nick
*** Bug 156718 has been marked as a duplicate of this bug. ***
I'd prefer if the KMainWindow code stayed as it is, for a couple of reasons: - KWin uses # in the window role as a slight help in window grouping; this could be however fixed with using setWindowRole() for the role - current code only makes sure the object name is unique, but the previous one actually extended it, by prepending the appname - session restore was broken because this was adding up - dbusName() is a clean solution, while relying on some expected objectName() value is a fragile hack and it's question whether this counts as breaking backwards compatibility - all uses of this can be found by searching for the "/.*objectName" regexp In short, it should be eventually much safer and less work to fix konq.
SVN commit 767274 by orlovich: Fix the nasty regression that resulted in konq opened from panel eating CPU, being barely responsive, and basically unable to load anything. (such as the stylesheet or images for the about page!) The problem is that KMainWindow::objectName changed, so the paths this returned via methods called from kfmclient were not valid, causing the connection to be dropped by the server. So use the new dbusName() instead. BUG:156658 M +8 -8 KonquerorAdaptor.cpp M +1 -1 konqview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=767274