GNOME Bugzilla – Bug 113020
Gnumeric crashes at start up with server fd is 0
Last modified: 2004-12-22 21:47:04 UTC
Package: Gnumeric Severity: normal Version: 1.1.16 Synopsis: Gnumeric crashes at start up with server fd is 0 Bugzilla-Product: Gnumeric Bugzilla-Component: General BugBuddy-GnomeVersion: 2.0 (2.2.0.1) Description: Description of Problem: As soon as you start gnumeric it craches, though when run in a console the following messags are displayed: Bonobo accessibility support initialized GTK Accessibility Module initialized Atk Accessibilty bridge initialized ** ERROR **: error condition on server fd is 0 aborting... Steps to reproduce the problem: 1. click on the gnumeric icon in the application menu, or type gnumeric at the console Actual Results: Gnumeric crashes and starts bug buddy. Expected Results: The main gnumeric window to open. How often does this happen? Always see below. Additional Information: I was using gnumeric to quickly look at some data when it crashed on me. since the crash, I always get the above problem. I loged out of X and kill all taskes own by the user. Other users still can open gnumeric so i assume the is a corupt setting somewhere? Debugging Information: Backtrace was generated from '/usr/bin/gnumeric' (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 16384 (LWP 6602)] (no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...0x40eb5af9 in wait4 () from /lib/libc.so.6
+ Trace 36887
Thread 1 (Thread 16384 (LWP 6602))
------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-05-14 18:31 ------- Reassigning to the default owner of the component, jody@gnome.org.
Appears to be a unique stack trace, according to the simple-dup-finder. Marking priority->high & severity->critical (it's a crasher), and marking as new.
I had a go at trying to find the problem this morning with some rather strange results. I decided to run gnumeric under strace to see if it shed any light on the problem. But when i run gnumeric under strace it start correctly, but (very slowly), but when you again try without strace the same crashing problem.
The problem is buried deep in the gnome library stack. The backtrace suggests that the 'linc' library is failing. I'll punt you over to them temporarilly to see if ther have more insight into what that symptom indicates.
You can prevent this bug from occuring by disabling accessibility by setting the gconf "desktop/gnome/interface/accessiblity flag to false. As such adding keyword accessibility This bug also may be related or even a dupe of #117561 Also ignore my last comment it now does crash when using strace for gnumeric version 1.1.19-bonobo
Paul's most recent comment is very interesting. I'm going to set priority to high to increase visiblity. Also, it's a crasher bug so I'm setting severity to critical. Finally, I'm going to select "Reassign to owner of selected component" since it appears that Jody forgot to do so.
Just an FYI: It appears that this is not the same bug as bug 117561--when Paul pointed out the similarity, I took a look and asked in that bug whether these two were the same. padraig.obriain@sun.com responded that he believes they are different.
This trace is rubbish & memory corrupted. g_get_current_time cannot call linc_ anything; and there's no chance that linc_protocol_find_num can crash at all. The trace is unrelated to that given in the warning. The warning is very odd - looks like a process starved of file descriptors; could there be an fd leak somewhere happening ? what OS is in use, also what versions of ORBit2, linc and libbonobo. Thanks.
Hmm, marking as AP3 for now to get it off our untriaged list... potentially higher if reproducible with other (core) apps though.
Set OS details as requested, and updated gnumeric version from 1.1.16 to 1.1.19 as I no longer have have the same version of gnumeric or the libs installed and no record of what they where as i had upgraded in hope the problem would vanish ;). But... Hear are the details on the current libs and a new backtrace from this version, which still showing the same visible problem ie it crashes with the same error message. Though the backtrace is different PS. The GLib-GObject-WARNING about link-selected are alway present when starting gnome applications with accessibilty enabled. libbonobo 2.2.3 libbonobo-acti 2.2.2 libbonoboui 2.2.2 ORBit2 2.6.2 linc 1.0.3 Backtrace was generated from '/usr/bin/gnumeric' (no debugging symbols found)...(no debugging symbols found)... (Last message repeted 22 times) (no debugging symbols found)...[New Thread 16384 (LWP 6672)] (no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (Last message repeted 12 times) (no debugging symbols found)...0x40ebcaf9 in wait4 () from /lib/libc.so.6
+ Trace 39239
Thread 1 (Thread 16384 (LWP 6672))
--Command line output: gnumeric Bonobo accessibility support initialized GTK Accessibility Module initialized (gnumeric:6672): GLib-GObject-WARNING **: gsignal.c:1082: unable to lookup signal "link-selected" for non instantiatable type `AtkHypertext' ** (gnumeric:6672): WARNING **: Invalid signal type link-selected (gnumeric:6672): GLib-GObject-WARNING **: gsignal.c:1082: unable to lookup signal "link_selected" for non instantiatable type `AtkHypertext' Atk Accessibilty bridge initialized ** ERROR **: error condition on server fd is 0 aborting...
*** Bug 118641 has been marked as a duplicate of this bug. ***
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
Could you try a later version of libbonobo*?
Still the same problem with the latest version from debain Package vesion deb-version libbonobo-activation 2.4.0 -3 libbonobo2 2.4.1 -2 libbonoboui2 2.4.0 -4 gnumeric 1.2.1 Do you want a new stack trace with the later versions?
The ORBit2 version is the interesting bit here, and there shouldn't be a bonobo-activation-2.4.0, it's part of libbonobo.
This is a duplciate of 121675 *** This bug has been marked as a duplicate of 121675 ***