Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 135499 - GNOME print related dialogs lockup
Summary: GNOME print related dialogs lockup
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: libgnomecups
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Owen Taylor
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 131589
TreeView+ depends on / blocked
 
Reported: 2004-10-13 03:26 UTC by Warren Togami
Modified: 2007-11-30 22:10 UTC (History)
5 users (show)

Fixed In Version: 0.1.12-5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-10-14 14:49:09 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

Description Warren Togami 2004-10-13 03:26:29 UTC 
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
Comment 1 Warren Togami 2004-10-13 07:45:06 UTC 
I suspect this is somehow related to Bug #135502.
Comment 2 Tim Waugh 2004-10-13 12:17:01 UTC 
I don't think this is related to bug #135502.
Comment 3 Colin Walters 2004-10-13 16:43:23 UTC 
Can you give the output of 't a a bt'?
Comment 4 Colin Walters 2004-10-13 17:16:37 UTC 
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?
Comment 5 Warren Togami 2004-10-14 07:26:37 UTC 
It appears that the package did not build?  Please advise.
Comment 6 Warren Togami 2004-10-14 09:01:26 UTC 
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"!
Comment 7 Warren Togami 2004-10-14 13:02:21 UTC 
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.
Comment 8 Alexander Larsson 2004-10-14 14:18:52 UTC 
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.
Comment 9 Colin Walters 2004-10-14 14:49:09 UTC 
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.
Note You need to log in before you can comment on or make changes to this bug.