GNOME Bugzilla – Bug 154965
crashes unless --no-config is used
Last modified: 2004-12-22 21:47:04 UTC
Distribution: Gentoo Base System version 1.5.3 Package: gDesklets Severity: critical Version: GNOME2.8.0 0.26 Gnome-Distributor: Gentoo Linux Synopsis: crashes unless --no-config is used Bugzilla-Product: gDesklets Bugzilla-Component: core Bugzilla-Version: 0.26 BugBuddy-GnomeVersion: 2.0 (2.8.0) Description: Description of the crash: Steps to reproduce the crash: 1. start gdesklets 2. wait 3. coredump Expected Results: It starts How often does this happen? always Additional Information: it does not happen with --no-config ------- Bug moved to this database by unknown@bugzilla.gnome.org 2004-10-09 08:40 ------- Unknown platform unknown. Setting to default platform "Other". Unknown milestone "unknown" in product "gDesklets". Setting to default milestone for this product, '---' Setting to default status "UNCONFIRMED". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
gdesklets can't segfault or coredump. If it does, that's because of a broken build.
Thanks for your helpful (and actually false) answer. sgala@marlow ~ $ equery files gdesklets-core | egrep "lib[^/]*\.so" /usr/share/gdesklets/libdesklets/_glibtopmodule.so
Created attachment 32428 [details] LC_ALL=C strace gdesklets &>/tmp/canthappen.txt This is the output of a call to it, to see if anyone can make sense of it. I pressed "Close" this time, instead of "Inform Developers"
equery files gdesklets-core | egrep "lib[^/]*\.so" /usr/share/gdesklets/libdesklets/_glibtopmodule.so what does this mean ?
It means there is a binary library in the package, which means it can dump core. Determining that a program can't dump core is actually as difficult a problem as Turing's termination test, I'd say. (coming from a java programmer who has said "java can't dump core" and proved false quite a few times) In fact the problem is quite probably not there, but in the pygtk or gnome-python packages on which gdesklets depends. I rebuilt those, to no avail. If someone can make sense of the strace, nice. It is one of the reasons why using gdesklets is not practical for me: using --no-config, it runs, but it does not keep the configuration. I can rebuild with +debug and gdb the whole python + pygtk + gnome-python + gdesklets thing, if needed. FWIW, I'm running straw (a python program which depends on gnome-python and pygtk) every day, with not a single problem. And programming python and runnning it continuously. Not to mention that the gentoo packaging is written in python.
If it works with --no-config, then the crash occurs when using GConf. If you are using PyGTK 2.4, then make sure that you're using gnome-python 2.6 as well. If the crash then still occurs, we'll have to take a closer look at the GConf bindings.
This is it. Thanks. Current ~ppc (testing,ppc) in gentoo for those packages is: - pygtk 2.4.0 - pyorbit 2.0.0 - gnome-python 2.0.2 I built in my overlay tree - pyorbit 2.0.1 (required for a full build of gnome-python) - gnome-python 2.6.0 And it runs quite well now. Thanks. I'll file a bug there telling about the incompatibility of the packages WRT gdesklet, and potential for other things. Thanks for your help.
The report was already there, opened like at the same time: http://bugs.gentoo.org/show_bug.cgi?id=66893
it's basicly the same problem that was on debian. gnome-python2.0 works really bad with pygtk2.4. IIRC, i was able to locate the segfault in gconf code, as said pycage. so who was right ? :D
> "gdesklets can't segfault or coredump." gdesklets segfaulted, no matter where is the bug that makes it happen. >"If it does, that's because of a broken build." No broken build, I built it from sourced and it (neither the other packages) stopped the build because of some version mismatch or dependency. Some bugs are difficult to track, but negating them is never a good start The question for me, rather than who was right, is who was helpful. Thanks, Martin, for pointing me in the right direction.
I didn't negate anybug. But you can't blame gdesklets if gnome-python is broken with your pygtk. As you can see, no changes in gdesklets code were needed to make it run. We're experiencing a lot of bug due to broken external libraries (for example libgtop<2.6) and we're trying to do our best to deal with them. But sometimes, we can't do anything at all. FYI, we have no C code about gconf. We should have reassigned this bugzilla to gnome-python.
*** Bug 154745 has been marked as a duplicate of this bug. ***