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): libgnomecups-0.1.8.cvs20040621-2 How reproducible: Always Steps to Reproduce: 1. start gnumeric 2. wait <= 5 seconds Actual Results: crash Expected Results: not crash Additional info: 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 (gdb) bt #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 gmain.c:1942 #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 printers". 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.