Red Hat Bugzilla – Bug 128705
libgnomecups-0.1.8 blows up gnumeric
Last modified: 2007-11-30 17:10:46 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040720
Description of problem:
gnumeric 1.2.12-2 worked fine on fc3 previously, after yum update it
blows up soon after starting in g_timeout_dispatch.
Debugging shows that the timeout causing my woes seems to be from
libgnomecups. And indeed the big stupid patch attached to disable the
offenders makes my crash stop, though its clearly worthless as a fix.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. start gnumeric
2. wait <= 5 seconds
Actual Results: crash
Expected Results: not crash
no printer, up to date devel rawhide
Created attachment 102246 [details]
patch to help narrow down problem
Any ideas Colin?
Gnumeric works fine here on the latest rawhide. However if that patch
fixes things reliably for you, then it's probably my fault.
Where is it crashing, exactly? Can you get a backtrace? Is the
backtrace the same each time?
reliably I get
#0 0x00bbbdec in ?? ()
#1 0x0060f098 in g_timeout_dispatch (source=0x8eb6148, callback=0xbbbdec,
user_data=0x0) at gmain.c:3301
#2 0x0060c4eb in g_main_context_dispatch (context=0x8c78610) at
#3 0x0060df72 in g_main_context_iterate (context=0x8c78610, block=1,
dispatch=1, self=0x8c5b308) at gmain.c:2573
#4 0x0060e21f in g_main_loop_run (loop=0x8da3830) at gmain.c:2777
#5 0x008b87ce in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#6 0x0814bd42 in main (argc=0, argv=0x8c5b448) at main-application.c:239
which doesn't really help you I'd say :-)
Is this compiled with optimization? If so, could you recompile without?
0xbbbdec isn't a mapped address IIRC.
Ah wait, I can reproduce this now. I'd missed your original "no
Ok, after a quick audit I see we're not calling GDK_THREADS_ENTER in
some idle handler callbacks. Adding those and testing now...
Turned out to be a bug in our libgnomeprint patch - if there were no
printers, it was unloading the cups module, but several idle handlers
were still pointing to functions in the unmapped pages. We fixed it
by simply always keeping the module open, because new printers could
appear at any time.