Bug 128705 - libgnomecups-0.1.8 blows up gnumeric
libgnomecups-0.1.8 blows up gnumeric
Product: Fedora
Classification: Fedora
Component: libgnomecups (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Colin Walters
Depends On:
  Show dependency treegraph
Reported: 2004-07-28 09:09 EDT by Caolan McNamara
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version: 2.7.0-3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-07-29 17:00:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch to help narrow down problem (1.62 KB, patch)
2004-07-28 09:10 EDT, Caolan McNamara
no flags Details | Diff

  None (edit)
Description Caolan McNamara 2004-07-28 09:09:21 EDT
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):

How reproducible:

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
Comment 1 Caolan McNamara 2004-07-28 09:10:39 EDT
Created attachment 102246 [details]
patch to help narrow down problem
Comment 2 Owen Taylor 2004-07-28 09:42:40 EDT
Any ideas Colin?

Comment 3 Colin Walters 2004-07-28 10:55:24 EDT
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?
Comment 4 Caolan McNamara 2004-07-28 11:03:44 EDT
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
#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 :-)
Comment 5 Colin Walters 2004-07-28 11:43:32 EDT
Is this compiled with optimization?  If so, could you recompile without?
0xbbbdec isn't a mapped address IIRC.
Comment 6 Colin Walters 2004-07-28 12:31:19 EDT
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...
Comment 7 Colin Walters 2004-07-29 17:00:04 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.