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
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.