Bug 128705 - libgnomecups-0.1.8 blows up gnumeric
Summary: libgnomecups-0.1.8 blows up gnumeric
Alias: None
Product: Fedora
Classification: Fedora
Component: libgnomecups   
(Show other bugs)
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Colin Walters
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-07-28 13:09 UTC by Caolan McNamara
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version: 2.7.0-3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-07-29 21:00:04 UTC
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 13:10 UTC, Caolan McNamara
no flags Details | Diff

Description Caolan McNamara 2004-07-28 13:09:21 UTC
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 13:10:39 UTC
Created attachment 102246 [details]
patch to help narrow down problem

Comment 2 Owen Taylor 2004-07-28 13:42:40 UTC
Any ideas Colin?

Comment 3 Colin Walters 2004-07-28 14:55:24 UTC
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 15:03:44 UTC
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 15:43:32 UTC
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 16:31:19 UTC
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 21:00:04 UTC
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.