Version: 0.4 (using KDE KDE 3.3.92) Installed from: Compiled From Sources Compiler: gcc-3.4.3 OS: Linux Using konqueror I go to a web page and open a pdf with kpdf. The first time this works. If you then back arrow and try to open any other pdf in the same fashion, konqueror locks up.
Could be a duplicate of Bug #99242
Probably a dup of 99222 and 99363 A shame that noone has a valid backtrace and that i can't reproduce it
Neither can I. Some of these reporters are using recent builds. Any chance someone could upgrade to HEAD?
Tell me how to get a backtrace (of an app that technically hasn't crashed but is hung) and I can get it to you. I can reproduce this on two different boxes.
Have a look at http://bugs.kde.org/show_bug.cgi?id=98894 Comment #9 BTW if you are using Phase Style this is a know bug in its code and you have to update it?
it's not 98894. I'm not using Phase...I'm using Plastik. Also I can view the entire pdf on the first download, just as you would expect to be able to. Everything hangs when you try to open a second pdf.
I just realised you won't find a kpdf process number doing ps aux because you are embedding kpdf inside konqueror, so do the same but with konqueror. Hope i explain myself.
ok, sorry I misunderstood the earlier directions...I'll try the instructions shortly and report back.
If I may cut in. I use kde-3.4.0_beta2 from gentoo split ebuilds. When it hangs it prints to .xsession-errors the following lines: konqueror: Switching view modes... konqueror: Trying to create view for "application/pdf" kio (KTrader): query for application/pdf, Application : returning 2 offers kio (KTrader): query for application/pdf, KParts/ReadOnlyPart : returning 3 offers konqueror: kpdf_part : X-KDE-BrowserView-AllowAsDefault is valid : false konqueror: KonqView::switchView DCOP: unregister 'anonymous-29352' kio (KLauncher): KLauncher: Got start_service_by_name('KTTSD', ...) DCOPServer::DCOPReply for unknown connection.
Created attachment 9697 [details] backtrace from attaching to konqueror with kpdf
It looks like the code in part.cpp is starting KTTSD in order to determine if the context menu item should be enabled/displayed or not. Instead of starting KTTSD, which is something user might not want, you could detect if KTTSD is available something like this: // If KTTSD is not installed, hide action. KTrader::OfferList offers = KTrader::self()->query("DCOP/Text-to-Speech", "Name == 'KTTSD'"); if (offers.count() > 0) // Enable context menu option. else // Disable context menu option. Then if user chooses to speak text, start KTTSD if needed. Note: You may have to insert a delay after starting KTTSD before sending it text to speak. I have some code like this in kdebase/konqueror/kttsplugin/khtmlkttsd.cpp to deal with this: void KHTMLPluginKTTSD::slotReadOut() { DCOPClient *client = kapp->dcopClient(); // If KTTSD not running, start it. if (!client->isApplicationRegistered("kttsd")) { QString error; if (kapp->startServiceByName("KTTSD", QStringList(), &error)) QMessageBox::warning(0, i18n( "Starting KTTSD Failed"), error ); else { // Give KTTSD time to load. QTimer::singleShot(1000, this, SLOT(slotReadOut())); return; } } This may or may not be needed. I'm not sure.
Hi, that may be another bug (i'll try to fix it tomorrow), but the backtrace says that konqueror hangs at KApplication::startServiceByName() so that should not be the problem
Waldo says to use startServiceByDesktopName("kttsd", ..) rather than startServiceByName("KTTSD", ..), which eliminates need to wait for KTTSD to start up. And it may also fix this problem. :) if ( KApplication::startServiceByName( "kttsd" ) ) Settings::setUseKTTSD( false );
Thanks! It is fixed with part.cpp version 1.27.
Cool :-) Mike can you please try to update and see if it works for you too?
I had this problem in beta2, but in rc1 it works fine.
So could we close it as seems Waldo commit fixed it for those who were having the problem? Mike are you there? Can you test on KDE 3.4.0 RC1 too?
Anyone on this bug can test if this still happens for you in KDE 3.5.0 ?
Atleast for me it was already fixed in 3.4.0...
Ok, marking it as fixed, if it still happens for someone please reopen the bug.