Version: (using KDE 4.1.3) Compiler: gcc version 4.1.2 (Gentoo 4.1.2 p1.1) OS: Linux Installed from: Gentoo Packages When I attempt to print from any KDE4 application (e.g Okular), the print dialog takes a very long time to load (approx 10 minutes). During this time, the application is unusable, the print dialog is not shown, and there is apparently no way to cancel the action. I am using the CUPS print server, and my primary printer is set up as an IPP printer. Once the dialog finally displays, I can choose my printer from among the various other printers in the list, which are apparently discovered on the network as I have not configured them. Printing from non-KDE4 applications (such as firefox) do not experience similar delays. My strong suspicion is that the print dialog is initiating a network scan for printer discovery each time it is opened. If so, this is terribly inefficent and not very good network etiquette. Evidence of this is that setting "Browse Off" in my cupsd.conf file causes the delay to disappear. For me, this is an acceptable workaround, but I feel it should not be necessary. A utility dialog box should not be performing uncancelable, long duration I/O activities during its initilization which render the application unusable.
This is the first report we've had of such an issue so I wonder if there is something unique about your config or network that would cause this. Regardless, I'm afraid this isn't actually a KDE problem. The Print Dialog is provided by Qt and all dealings with CUPS including detecting printers is done within Qt. We don't do anything that might instigate a network scan, and I'm surprised Qt would feel the need to do so either. I would expect them to simply query the local CUPS server to see what Printers it already knows about. Anyway, could you please raise a bug report upstream at Qt http://trolltech.com/developer/task-tracker and post the link back here.
I have the same problem with openSUSE 11.1 and KDE 4.1.3. It only occurs on my notebook, when I have several network printers configured, which are in different networks, this means they are not all accessible at the same time. I tried to fill this upstream as suggested in comment 1, but I cannot find the report in there tasktracker.
I've found the following bug in the Qt tracker which may be the issue: http://www.qtsoftware.com/developer/task-tracker/index_html?method=entry&id=232664 It's Active status so someone may be working on it. Unfortunately, the Qt bug-tracker is a closed one and even less user-friendly than bko :-) You'll need to either create a new task or email qt-bugs@trolltech.com and leave it up to them to manage it from there. Please mention this bug in any report, post here the Qt entry number if you are assigned a new one, and post brief details of any info you find out. Thanks!
Sorry for the the Qt bug-tracker being too closed. We are working to have a more open development infrastructure but it takes time. I was not able to reproduce the problem on Qt 4.4.3 and Qt 4.5. It is possible the issue only appear with some special configuration I don't have. Does anybody with the problem could send a stack trace of "freezed" application? I will look at the cups API to find what we have done wrong.
This is a stacktrace grabbed from Okular via GDB while it was locked up waiting for the print dialog. My Qt version is 4.4.2, installed from Gentoo ebuilds. I've also attached some additional information about my machine. Let me know if you need more information. (gdb) info stack #0 0x00002b4bcffe9146 in poll () from /lib64/libc.so.6 #1 0x00002b4bcc6b5448 in ?? () from /lib64/libresolv.so.2 #2 0x00002b4bcc6b45f9 in __libc_res_nquery () from /lib64/libresolv.so.2 #3 0x00002b4bcc6b4817 in ?? () from /lib64/libresolv.so.2 #4 0x00002b4bcc6b4a9a in __libc_res_nsearch () from /lib64/libresolv.so.2 #5 0x00002aaab4a5f46f in _nss_dns_gethostbyname3_r () from /lib64/libnss_dns.so.2 #6 0x00002aaab4a5f65e in _nss_dns_gethostbyname_r () from /lib64/libnss_dns.so.2 #7 0x00002b4bd00052ce in gethostbyname_r () from /lib64/libc.so.6 #8 0x00002b4bd0004c23 in gethostbyname () from /lib64/libc.so.6 #9 0x00002aaab403f1e4 in httpGetHostname () from /usr/lib/libcups.so.2 #10 0x00002aaab4051e2e in cupsGetPPD2 () from /usr/lib/libcups.so.2 #11 0x00002b4bce78ef2f in ?? () from /usr/lib64/qt4/libQtGui.so.4 #12 0x00002b4bce78bbe4 in QPrinterInfo::availablePrinters () from /usr/lib64/qt4/libQtGui.so.4 #13 0x00002b4bce78be73 in QPrinterInfo::defaultPrinter () from /usr/lib64/qt4/libQtGui.so.4 #14 0x00002b4bce71158c in QPrinter::QPrinter () from /usr/lib64/qt4/libQtGui.so.4 #15 0x00002b4bd2fd83ea in ?? () from /usr/lib64/kde4/okularpart.so #16 0x00002b4bd2fddbae in ?? () from /usr/lib64/kde4/okularpart.so #17 0x00002b4bc9fb628c in QMetaObject::activate () from /usr/lib64/qt4/libQtCore.so.4 #18 0x00002b4bce5efc47 in QAction::triggered () from /usr/lib64/qt4/libQtGui.so.4 #19 0x00002b4bce5f0450 in QAction::activate () from /usr/lib64/qt4/libQtGui.so.4 #20 0x00002b4bce98178d in ?? () from /usr/lib64/qt4/libQtGui.so.4 #21 0x00002b4bcab90ed1 in KMenu::mouseReleaseEvent () from /usr/lib64/libkdeui.so.5 #22 0x00002b4bce6429e5 in QWidget::event () from /usr/lib64/qt4/libQtGui.so.4 #23 0x00002b4bce97f721 in QMenu::event () from /usr/lib64/qt4/libQtGui.so.4 #24 0x00002b4bce5f62be in QApplicationPrivate::notify_helper () from /usr/lib64/qt4/libQtGui.so.4 #25 0x00002b4bce5fb2cf in QApplication::notify () from /usr/lib64/qt4/libQtGui.so.4 #26 0x00002b4bcaadea0b in KApplication::notify () from /usr/lib64/libkdeui.so.5 #27 0x00002b4bc9fa22f8 in QCoreApplication::notifyInternal () from /usr/lib64/qt4/libQtCore.so.4 #28 0x00002b4bce5f8551 in QApplicationPrivate::sendMouseEvent () from /usr/lib64/qt4/libQtGui.so.4 #29 0x00002b4bce6585f3 in ?? () from /usr/lib64/qt4/libQtGui.so.4 #30 0x00002b4bce657263 in QApplication::x11ProcessEvent () from /usr/lib64/qt4/libQtGui.so.4 #31 0x00002b4bce67af15 in ?? () from /usr/lib64/qt4/libQtGui.so.4 #32 0x00002b4bc9fa1675 in QEventLoop::processEvents () from /usr/lib64/qt4/libQtCore.so.4 #33 0x00002b4bc9fa17d8 in QEventLoop::exec () from /usr/lib64/qt4/libQtCore.so.4 #34 0x00002b4bc9fa34fe in QCoreApplication::exec () from /usr/lib64/qt4/libQtCore.so.4 #35 0x0000000000407eee in _start () Portage 2.1.6.4 (default/linux/amd64/2008.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.24-gentoo-r8Gentoo2 x86_64) ================================================================= System uname: Linux-2.6.24-gentoo-r8Gentoo2-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_3800+-with-glibc2.2.5 Timestamp of tree: Fri, 09 Jan 2009 21:15:01 +0000 app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7-r1, 2.1.6-r1 dev-lang/python: 2.4.4-r13, 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 dev-util/cmake: 2.6.2 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe" CHOST="x86_64-pc-linux-gnu"
Thanks robert, exactly what I needed. This bug is the same as in: http://www.qtsoftware.com/developer/task-tracker/index_html?method=entry&id=232664 I have added a note to this task to describe the problem. The problem comes from a blocking call to cupsGetPPD (http://www.cups.org/documentation.php/api-cups.html#cupsGetPPD) Unfortunately, cups do not provide a non blocking call for this. A solution may be to create first a non blocking socket to test the connection, unless you have a better idea?
*** Bug 183156 has been marked as a duplicate of this bug. ***
*** Bug 188007 has been marked as a duplicate of this bug. ***
I have the same problem, forces me to use non-KDE apps for printing Any idea how this can be worked around? Is this a network/configuration issue maybe, since it takes so long to resolve the hostname?
Gnome has the same bug it seems: https://bugs.launchpad.net/ubuntu/+source/gnome-print/+bug/223776
Found my issue, it was a misconfigured /etc/hosts file (which would be an OpenSuse bug, since I never touched it). It was missing my hostname. I added 127.0.0.1 <myhostname> to it (where <myhostname>==my actual host name, the output of "hostname"). Other people seem to have the same problem, or an IPP printer that is no longer connected.
*** Bug 207890 has been marked as a duplicate of this bug. ***
*** Bug 208943 has been marked as a duplicate of this bug. ***
*** Bug 212338 has been marked as a duplicate of this bug. ***
The /etc/host "fix" is not a fix for me. As per my duplicate bug above it still appears that KDE is downloading ppd files far more than it needs to and this is creating extra delays when compared to other apps, (i.e.gnome/gtk apps).
Andrew, 127.0.0.1 <myhostname> is not enough. You need, for example: 192.168.0.1 <myhostname> on the /etc/hosts if your cups server is 192.168.0.1. (unless of course there is a local dns zone that makes IPs resolvable). Bottom lime: cups needs to resolve its own LAN IP. The problem can be tested with: wget --no-check-certificate https://192.168.0.2:631/printers/PRINTERPPD.ppd It it takes long the KDE Print Dialog will take long as well. Once /etc/hosts is fixed wget will be very fast.
Forgot to mention that cups must be restarted after changing /etc/hosts
I have this problem, too. Distribution: Ubuntu 12.10 cups: 1.6.1 Qt: 4.8.3 KDE: 4.9.2 Okular: 0.15.2 kate: 3.9.2 Configurations: In /etc/cups/client.conf, I configured cups to use a server (real hostname replaced): ServerName foo.bar.baz In /etc/cups/cupsd.conf, I added this line (the same host as above) BrowsePoll foo.bar.baz On the server foo.bar.baz, there are 25 printers. The Problem: Invoking the "Print..." item from the file menu of any KDE application (including kate and Okular) causes the application to freeze up. But non-kde applications can print without problem. Evince, for example, opens its printing dialog as soon as the file->print menu item is invoked. Then its dialog refreshes the status of the printers periodically. Here is a stack trace of Okular from GDB while Okular is frozen for printing: ======CUT HERE========= (gdb) backtrace #0 0x00007ffff5217303 in poll () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007fffdb5c54a3 in _httpWait () from /usr/lib/x86_64-linux-gnu/libcups.so.2 #2 0x00007fffdb5c5e0e in httpRead2 () from /usr/lib/x86_64-linux-gnu/libcups.so.2 #3 0x00007fffdb5c61a0 in httpFlush () from /usr/lib/x86_64-linux-gnu/libcups.so.2 #4 0x00007fffdb5e1319 in cupsDoIORequest () from /usr/lib/x86_64-linux-gnu/libcups.so.2 #5 0x00007fffdb5e72e9 in cupsGetDefault2 () from /usr/lib/x86_64-linux-gnu/libcups.so.2 #6 0x00007fffdb5bb4b3 in cupsGetDests2 () from /usr/lib/x86_64-linux-gnu/libcups.so.2 #7 0x00007ffff67e1437 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #8 0x00007ffff67e15f5 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #9 0x00007ffff673bb9a in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #10 0x00007ffff6750d36 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #11 0x00007ffff675290f in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #12 0x00007ffff6754f3d in QPrinter::init(QPrinter::PrinterMode) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #13 0x00007ffff67556f8 in QPrinter::QPrinter(QPrinter::PrinterMode) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #14 0x00007fffe66ab30c in ?? () from /usr/lib/kde4/okularpart.so #15 0x00007fffe66abf5a in ?? () from /usr/lib/kde4/okularpart.so #16 0x00007ffff5bf9f5f in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #17 0x00007ffff65c0a32 in QAction::triggered(bool) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #18 0x00007ffff65c0c20 in QAction::activate(QAction::ActionEvent) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #19 0x00007ffff69ff3d3 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #20 0x00007ffff6a056b9 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #21 0x00007ffff7388090 in KMenu::mouseReleaseEvent(QMouseEvent*) () from /usr/lib/libkdeui.so.5 #22 0x00007ffff6616850 in QWidget::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #23 0x00007ffff6a0696b in QMenu::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #24 0x00007ffff65c6e9c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #25 0x00007ffff65cbb6b in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #26 0x00007ffff72cf1d6 in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5 #27 0x00007ffff5be456e in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #28 0x00007ffff65c7cd3 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #29 0x00007ffff664541c in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #30 0x00007ffff664444f in QApplication::x11ProcessEvent(_XEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #31 0x00007ffff666bfa2 in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #32 0x00007ffff1e16ab5 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #33 0x00007ffff1e16de8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #34 0x00007ffff1e16ea4 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #35 0x00007ffff5c12bf6 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #36 0x00007ffff666bc1e in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #37 0x00007ffff5be32bf in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #38 0x00007ffff5be3548 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #39 0x00007ffff5be8708 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #40 0x00000000004079ce in ?? () #41 0x00007ffff515076d in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #42 0x00000000004081fd in _start () ========CUT HERE============= I captured the IPP traffic using Wireshark. Okular, though frozen after asked to print, still communicates with the server periodically using IPP. The most frequently sent operations are 0x4002 (CUPS-Get-Printers). 0x4001 (CUPS-Get-Default) and 0x000b (Get-Printer-Attributes) are also used.
The error is in my own configuration of CUPS. In /etc/cups/client.conf, I configured cups to use a server: "ServerName foo.bar.baz" This will cause all CUPS clients to communicate with foo.bar.baz directly via the network, which is really slow. Even this simple program found on CUPS' official site (http://cups.org/documentation.php/doc-1.6/api-overview.html) takes one minute to run. That problem is not in Qt nor Kde. Remove the line "ServerName foo.bar.baz" and the printer dialog no longer freeze the whole program.
(In reply to comment #19) > > That problem is not in Qt nor Kde. > https://bugreports.qt-project.org/browse/QTBUG-10425
Note that there was the idea to add a handling upstream in the Qt print dialog to handle the case where attempting to retrieve the PPD from a remote CUPS server takes a long time to not block the UI, s. e.g. the change at [1] , in particular the comments on patch set 4 [2]. The patch set was dropped in the end though, since the underlying issue is a CUPS one and the behaviour has changed in the most recent CUPS version 2.2.7, s. [2] and also the CUPS issue [3] that describes that the new behaviour is intended. The problem should no longer occur with CUPS version 2.2.7 or later or with a modified setup as suggested by CUPS developer Michael Sweet in [3]. I'm therefore closing this bug report as RESOLVED UPSTREAM. [1] https://codereview.qt-project.org/#/c/225203/ [2] https://codereview.qt-project.org/#/c/225203/4//ALL [3] https://github.com/apple/cups/issues/5293