Description of problem: Many GNOME print related dialogs tend to lockup, sometimes for several minutes, sometimes forever. The below backtrace is from gnome-printinfo after it locked up while browsing the print queue. (gdb) bt #0 0x00934782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00b9420e in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0 #2 0x00b90dbf in _L_mutex_lock_32 () from /lib/tls/libpthread.so.0 #3 0x00b94321 in __lll_mutex_unlock_wake () from /lib/tls/libpthread.so.0 #4 0x00d40da0 in g__string_mem_chunk_lock () from /usr/lib/libglib-2.0.so.0 #5 0xfef5af38 in ?? () #6 0x00119452 in close_unused_connection (server=0x8bc6c10 "\002", connection=0xb9420e, current_time=0xfffffffc) at gnome-cups-request.c:249 #7 0x00119452 in close_unused_connection (server=0x8bc7628 "ibmlaptop", connection=0x8bc69f0, current_time=0xfffffffc) at gnome-cups-request.c:249 #8 0x00cdf8be in g_hash_table_foreach_remove_or_steal (hash_table=0x89f2e78, func=0x1193cf <close_unused_connection>, user_data=0xfef5af88, notify=1) at ghash.c:502 #9 0x0011951e in idle_close_unused_connections (unused=0x0) at gnome-cups-request.c:269 #10 0x00cec0a8 in g_timeout_dispatch (source=0x89d5008, callback=0xb94321 <__lll_mutex_unlock_wake+33>, user_data=0xfffffffc) at gmain.c:3301 #11 0x00ce94fb in g_main_context_dispatch (context=0x89e80b8) at gmain.c:1942 #12 0x00ceaf82 in g_main_context_iterate (context=0x89e80b8, block=1, dispatch=1, self=0x89c8df0) at gmain.c:2573 #13 0x00ceb22f in g_main_loop_run (loop=0x8a89310) at gmain.c:2777 #14 0x003a76ce in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #15 0x08064d49 in main (argc=12141345, argv=0xb94321) at main.c:326 Version-Release number of selected component (if applicable): libgnomecups-0.1.12-4
I suspect this is somehow related to Bug #135502.
I don't think this is related to bug #135502.
Can you give the output of 't a a bt'?
Ok, we found a potential case where the main thread could block on an unavailable CUPS server. Can you try the latest package 0.1.12-5 when it makes it through beehive?
It appears that the package did not build? Please advise.
One occurance of this happening is after I attempt to cancel a job in the queue. cups error.log says: E [13/Oct/2004:23:01:36 -1000] cancel_job: "warren" not authorized to delete job id 1 owned by "root"!
Ah, this is solved in -5! Unfortunately it was moved to dist-fc3-HEAD, meaning it was rejected from FC3. Need to convince Sopwith to move it back because this is YellowPad.
Maybe the changelog should have referenced this bug nr so Sophwith knew what it fixed. "tries to avoid blocking the main loop in certain cases" doesn't sound very important.
He asked me on irc about it and I pointed him to the bug, probably he just forgot to do the move. I went ahead and did it myself.