Red Hat Bugzilla – Bug 962456
[abrt] Xnee-3.15-2.fc18: main: Process /usr/bin/gnee was killed by signal 6 (SIGABRT)
Last modified: 2013-07-05 20:55:04 EDT
Description of problem:
Immediate failure on launch. Just run "gnee" with no arguments and it crashes right away.
Version-Release number of selected component:
var_log_messages: May 13 09:17:35 swan abrt: Saved core dump of pid 6454 (/usr/bin/gnee) to /var/tmp/abrt/ccpp-2013-05-13-09:17:35-6454 (12345344 bytes)
Thread no. 1 (0 frames)
Created attachment 747247 [details]
Created attachment 747248 [details]
Created attachment 747249 [details]
Created attachment 747250 [details]
Created attachment 747251 [details]
Created attachment 747252 [details]
Created attachment 747253 [details]
Created attachment 747254 [details]
Created attachment 747255 [details]
Thanks for the bug report
I can't reproduce this bug on F19 (same version of Xnee)
In additional information, have you tested in other DE ?
I'm not sure exactly what you mean by "other DE". But I do have a few virtual machines handy:
In a GNOME Shell session under Fedora 17 , gnee crashes immediately, every time.
In a GNOME Shell session under Fedora 18, gnee crashes immediately, every time.
In a GNOME Shell session under Fedora 19 alpha plus all subsequent updates, gnee crashes immediately, every time.
I'm happy to try additional variations if you have something specific in mind.
sorry I meant DE = Desktop Environment = GNOME, KDE, LXDE, Xfce, etc...
If you have one of these installed on your system, could you try to launch it?
I installed KDE on my existing Fedora 18 virtual machine. In a KDE Plasma session, gnee crashes immediately, every time.
I can't to do more, I've forwarded this report to upstream mailing-list.
Gnee is not maintained anymore but I will try to fix it.
/Henrik (GNU Xnee maintainer)
Installed F18 in a vbox and executed gnee (as compiled on a Ubuntu 13.04) and gnee does not crash.
Here's the gnee binary I launched:
Can some one else try the binary above?
Your binary works for me in vm kvm f18
Also I tried gnee from the rpm in f18 repository and it works too (in the same vm)
The binary offered in comment #16 is for x64-64 (64-bit). In my original report, I set the "Hardware" field to reflect that I was seeing this on i686 (32-bit).
I've tried the standard RPM-installed gnee on an x86-64 Fedora 19 beta virtual machine. It works fine. But the standard RPM-installed gnee still fails consistently on any i386/i686 virtual machine I've tried. So whatever the problem is, it seems to be 32-bit specific.
Yep I've forgotten to be more precise: All of my tests are on x86_64 systems
So I'm searching in Fedora buildsystem logs differencies between the build for i686 and x86_64
F18 (32bit) up and running in a vbox. Gnee is working (CVS latest).
Here's a binary
Can you try that?
Packages I had to install to get compilation/linking working:
libtool automake17 autoconf
Gnee can't record XI events (Xnee can). Will fix that while we're at it.
The latest nightly dist contains the latest sources if you prefer to build as you would when producing the rpm package:
The binary offered in comment #21 works for me. No crash.
Ok. Thanks a lot!
Will prepare a 3.16 release of Xnee (including the new XI fixes or gnee).
Excellent. Thank you for giving this your attention, Henrik!
3.16 dist file:
.. many thanks for your work!!!
Updating the rpm, it will be pushed in few days in repository
Xnee-3.16-1.fc18 has been submitted as an update for Fedora 18.
Xnee-3.16-1.fc19 has been submitted as an update for Fedora 19.
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing Xnee-3.16-1.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Xnee-3.16-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Xnee-3.16-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.