Bug 445981
| Summary: | gnome-config <-> pkg-config recursion dangerous | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jason Vas Dias <jvdias> |
| Component: | gnome-libs | Assignee: | Paul Howarth <paul> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | 9 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 1.4.2-9.fc9 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-06-14 04:16:38 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
After
$ mv /usr/bin/gnome-config /usr/bin/gnome-config-broken
system is again usable and gnome-desktop does start - but what else relies on
gnome-config?
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping I'm unable to reproduce this:
$ strace -f -e trace=execve -e trace=open pkg-config --variable=libdir glib
open("/etc/ld.so.cache", O_RDONLY) = 3
open("/lib64/libc.so.6", O_RDONLY) = 3
open("/usr/lib64/pkgconfig", O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) = 3
open("/usr/share/pkgconfig", O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) = 3
open("/usr/lib64/pkgconfig/glib.pc", O_RDONLY) = 3
/usr/lib64
$ rpm -qa gnome-libs\* glib-\* pkgconfig | sort
glib-devel-1.2.10-29.fc9.i386
glib-devel-1.2.10-29.fc9.x86_64
gnome-libs-1.4.2-8.fc9.i386
gnome-libs-1.4.2-8.fc9.x86_64
gnome-libs-devel-1.4.2-8.fc9.i386
gnome-libs-devel-1.4.2-8.fc9.x86_64
pkgconfig-0.23-2.fc9.x86_64
gnome-config does indeed call pkgconfig for glib, but I can't see where you're
getting the callback to gnome-config from. The pkg-config file for glib is very
simple and doesn't call gnome-config (as indeed it shouldn't since gnome-libs is
higher up the dependency chain than glib):
$ cat /usr/lib64/pkgconfig/glib.pc
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib64
includedir=/usr/include
Name: GLib
Description: C Utility Library
Version: 1.2.10
Libs: -L${libdir} -lglib
Cflags: -I${includedir}/glib-1.2 -I${libdir}/glib/include
I'm similarly confused as to how any call to gnome-config has made it into your
desktop session startup. After all, gnome-config is a developer tool for the
ancient Gnome-1 libraries.
Any thoughts on that?
I've just run into this bug independently. I'm using Fedora 8 on x86_64. I've tracked it down to happening because glib-devel-1.2.10-28.fc8.i386 is installed, but not glib-devel-1.2.10-28.fc8.x86_64. Installing the x86_64 package fixes the problem. pkg-config calls gnome-config as a fallback when it can't find a package, apparently, running it via the "system()" call. This is a major annoyance, though, in that any call to pkg-config with an unknown or not installed package name results in a recursive gnome-config <-> pkg-config loop resulting in an out-of-memory situation. In other words, just about every ./configure script will trigger this. I never intentionally installed glib-devel-1.2.10-28.fc8.i386, I suspect it was installed by yum as a dependency for something else (probably glade3, looking at my `rpm -qa --last` output). Ah, looking at the pkg-config code I see this undocumented (in the manpage at least) behaviour (in parse.c). Thanks for tracking that down. I've prepared an update (gnome-libs-1.4.2-9.fc*) that two things to avoid this issue: 1. gnome-libs-devel now has a file dependency on glib.pc that will pull in the same-arch version of glib-devel and hence resolve the reporter's issue. 2. the first fix is not sufficient to prevent problems if someone just does "yum install gnome-libs-devel.i386" on F9. That will result in 32-bit versions of gnome-libs-devel and glib-devel, and a 64-bit pkg-config. The 64-bit pkg-config won't find the 32-bit glib.pc file and will fall back to gnome-config, which would fail as before. So I've also hacked gnome-config to test for the pkg-config calls that happen in this situation and to output results as best I can without calling pkg-config back, thus breaking the recursion. F9 update: http://koji.fedoraproject.org/koji/buildinfo?buildID=50742 F8 update: http://koji.fedoraproject.org/koji/buildinfo?buildID=50749 I'll request that these get pushed to updates-testing. gnome-libs-1.4.2-9.fc9 has been submitted as an update for Fedora 9 gnome-libs-1.4.2-9.fc8 has been submitted as an update for Fedora 8 gnome-libs-1.4.2-9.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gnome-libs'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-4658 Yes, this is fixed now. Thank you! gnome-libs-1.4.2-9.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report. gnome-libs-1.4.2-9.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: Running a fresh "Everything" install of rawhide 2008-05-10 x86_64 ( FC-9 ), with the gnome desktop and display manager selected, results in runaway gnome-config <-> pkg-config recursive process growth and system overload & eventual crash. It is a really dangerous bad idea to write program A that invokes program B which invokes program A, as is the case with the current gnome-config and pkg-config programs. OK, I know the usual caveats about rawhide useability / reliability, but really! $ grep -n pkg-config /usr/bin/gnome-config 13:libdir=`pkg-config --variable=libdir glib $ strace -f -o /tmp/death.log -e trace=execve -e trace=open \ pkg-config --variable=libdir glib # system overload of pkg-config invoking gnome-config which invokes pkg-config # results. The death.log will be a huge sequence of lines like: 26771 execve("/usr/bin/gnome-config", ["gnome-config", "--libs", "glib"], [/* 24 vars */]) = 0 26772 execve("/usr/bin/pkg-config", ["pkg-config", "--variable=libdir", "glib"], [/* 24 vars */]) = 0 26773 execve("/bin/sh", ["sh", "-c", "gnome-config --libs glib > /dev/null 2>&1"], [/* 24 vars */]) = 0 26779 execve("/usr/bin/gnome-config", ["gnome-config", "--libs", "glib"], [/* 24 vars */]) = 0 Whenever the gnome-desktop starts up, then, runaway process growth of recursive gnome-config -> pkg-config -> gnome-config invocations and system crash results. Version-Release number of selected component (if applicable): rawhide-2008-05-10 gnome-libs-1.4.2-8.fc9.i386 gnome-libs-1.4.2-8.fc9.x86_64 pkgconfig-0.23-2.fc9.x86_64 How reproducible: 100% Steps to Reproduce: Install from rawhide and try to start desktop Actual results: System overload and eventual crash Expected results: gnome desktop