GNOME Bugzilla – Bug 157829
print list should be populated asyncronously
Last modified: 2005-02-18 17:44:36 UTC
I see this problem with both gedit and gnumeric: I have 2 cups printers. In the application I select `print' then choose one printer and click on the configure button. then selct `close' in the configure dialog. afterwards alternate between selecting one and then the otehr printer. After 3 or 4 switches the print dialog becomes non-responsive.
I'm unable to replicate this. There are too many possibilities to figure this out - cups thread hanging - some sort of dialog problem with nested main loops?
back traces at the time of a hang seem useless: Program received signal SIGINT, Interrupt.
+ Trace 51823
Thread 65541 (LWP 16175)
Some further observations: It seems I do not need to have opened the configure dialog. Just switching between the 2 printers fac and lp suffices (90% of the time) provided I am online, ie. the printer fac is in fact accessible. Online here means a slow dial-up: to get the ppd file for that printer takes 3 or 4 seconds. While gnumeric is running I see groups of 3 threads being created. The hang always seems to happen just before the 3rd group should be created. It definitely looks like it has something to do with those threads when there is some slow communication with one printer.
I'm going to guess that this a is a libgnomecups problem. Once things have started try setting the magic global variable _gnome_cups_debug to TRUE. Let's see if that sheds any light on where things freeze. Another possibility (although unlikely) would be that it's somehow getting to the authentication bogosity. We can add a g_warning in cups_password_cb
Any feedback here ? This worries me.
setting _gnome_cups_debug to TRUE does not provide any useful information: ---->>> locking 0x88f5218 attributes-charset [0] = 'utf-8' attributes-natural-language [0] = 'en' <<<<----- unlocking 0x88f5218 ---->>> locking 0x88f5218 attributes-charset [0] = 'utf-8' attributes-natural-language [0] = 'en' <<<<----- unlocking 0x88f5218 ---->>> locking 0x88f5218 attributes-charset [0] = 'utf-8' attributes-natural-language [0] = 'en' printer-uri [0] = 'ipp://localhost/printers/lp' <<<<----- unlocking 0x88f5218 ---->>> locking 0x88f5218 attributes-charset [0] = 'utf-8' attributes-natural-language [0] = 'en' printer-uri [0] = 'ipp://localhost/printers/lp' requested-attributes [0] = 'printer-state' [1] = 'queued-job-count' [2] = 'printer-location' [3] = 'printer-info' [4] = 'printer-state-message' [5] = 'device-uri' [6] = 'printer-state-reasons' [7] = 'printer-info' [8] = 'printer-make-and-model' [9] = 'printer-uri-supported' (gnumeric:12687): GnomePrintCupsPlugin-WARNING **: iconv does not support ppd character encoding: ISOLatin1, trying CSISOLatin1 <<<<----- unlocking 0x88f5218 ---->>> locking 0x88f5218 attributes-charset [0] = 'utf-8' attributes-natural-language [0] = 'en' printer-uri [0] = 'ipp://localhost/printers/fac' <<<<----- unlocking 0x88f5218 ---->>> locking 0x88f5218 attributes-charset [0] = 'utf-8' attributes-natural-language [0] = 'en' printer-uri [0] = 'ipp://localhost/printers/fac' requested-attributes [0] = 'printer-state' [1] = 'queued-job-count' [2] = 'printer-location' [3] = 'printer-info' [4] = 'printer-state-message' [5] = 'device-uri' [6] = 'printer-state-reasons' [7] = 'printer-info' [8] = 'printer-make-and-model' [9] = 'printer-uri-supported' <<<<----- unlocking 0x88f5218 ---->>> locking 0x88f5218 attributes-charset [0] = 'utf-8' attributes-natural-language [0] = 'en' <<<<----- unlocking 0x88f5218 ---->>> locking 0x8786870 attributes-charset [0] = 'utf-8' attributes-natural-language [0] = 'en' printer-uri [0] = 'ipp://cups.lab.math.concordia.ab.ca/printers/fac' requested-attributes [0] = 'printer-state' ---->>> locking 0x8786520 attributes-charset [0] = 'utf-8' attributes-natural-language [0] = 'en' printer-uri [0] = 'ipp://kirkman:631/printers/lp' requested-attributes [0] = 'printer-state' [1] = 'queued-job-count' [2] = 'printer-location' [3] = 'printer-info' [4] = 'printer-state-message' [5] = 'device-uri' [1] = 'queued-job-count' [2] = 'printer-location' [3] = 'printer-info' [4] = 'printer-state-message' [5] = 'device-uri' [6] = 'printer-state-reasons' [7] = 'printer-info' [8] = 'printer-make-and-model' [9] = 'printer-uri-supported' [6] = 'printer-state-reasons' [7] = 'printer-info' [8] = 'printer-make-and-model' [9] = 'printer-uri-supported' <<<<----- unlocking 0x8786870 Note that the last output occurs several selection cycles before the programs hang.
Adding a g_warning in cups_password_cb does not yield any new information. We do not seem to get into that function.
Looking a t the debug spew again one notices that we have ---->>> locking 0x8786870 ---->>> locking 0x8786520 <<<<----- unlocking 0x8786870 We never seem to have unlocking for 0x8786520
The hang was due to a misconfiguration on the test machine. Nevertheless it exposed a more general problem: libgnomeprint/libgnomecups uses the device uri of a printer thereby bypassing the configured cupsd server. As a result if the device uri is temporarily unreachable, programs using libgnomeprint/libgnomecups will hang although the primary server may be available and responsive (and would hold any printjob until the printer becomes again available.) This design makes libgnomeprint/libgnomecups depending on the network status even if the cups setup would normally hide the problem.
I've commited a small patch to bypass that optimization. That doesn't solve all of the problem though. Even if the connection to the remote machine was blocking and timing out, the ui should not freeze. For 2.9.x we need to fix the ui to be fully async about printer attribute updates.
Some new information has come in 1) It was not a hang, just a long delay until the attempted connection timed out 2) The patch to disable the optimzation to go diectly to remote servers is in and avoid the delay 3) We really should not be pulling in any of this information syncronously
Given your #2, Jody, I think it is safe to say that this isn't a 2.10 showstopper- is that correct?
luis : It's not a show stopper, but it is a high priority. In environments with broken cups/network we can end up blocking a long time Unfortunately we appear to have lost the bangalorian I'd been talking to on this.
Jody, you are aware that we still haven't gotten all RH async patches upstreamed ? They address the issue by making all cups requests asynchronously. Do you want me to attach the outstanding patches here ?
mathias : yes, please.
Matthias doesn't appear to be on the cc list, so I'm adding him to make sure he gets Jody's comment...
Created attachment 36984 [details] [review] async interface for getting the ppd
Created attachment 36985 [details] [review] small locking fix
Created attachment 36987 [details] [review] retrieve printers asynchronously in libgnomeprint
Created attachment 36988 [details] [review] retrieve ppds asynchronously in libgnomeprint (I think the previous patch may apply after this one)
Created attachment 36990 [details] [review] make libgnomeprintui work with async retrieval
Comment on attachment 36987 [details] [review] retrieve printers asynchronously in libgnomeprint I've committed a variant of this.
What about the other patches ?
Ok, thats the last of them. The code copied from cups is a somewhat scary, but give the speed of development there it's unlikely to cause problems.