Bug 445981 - gnome-config <-> pkg-config recursion dangerous
Summary: gnome-config <-> pkg-config recursion dangerous
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-libs
Version: 9
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Paul Howarth
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-10 23:59 UTC by Jason Vas Dias
Modified: 2008-06-14 04:16 UTC (History)
0 users

Fixed In Version: 1.4.2-9.fc9
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-06-14 04:16:38 UTC


Attachments (Terms of Use)

Description Jason Vas Dias 2008-05-10 23:59:06 UTC
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

Comment 1 Jason Vas Dias 2008-05-11 00:29:13 UTC
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?


Comment 2 Bug Zapper 2008-05-14 10:58:51 UTC
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

Comment 3 Paul Howarth 2008-05-15 12:50:23 UTC
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?

Comment 4 Amish S. Dave 2008-05-27 22:58:05 UTC
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).


Comment 5 Paul Howarth 2008-05-28 14:02:04 UTC
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.

Comment 6 Fedora Update System 2008-05-28 15:07:00 UTC
gnome-libs-1.4.2-9.fc9 has been submitted as an update for Fedora 9

Comment 7 Fedora Update System 2008-05-28 15:08:02 UTC
gnome-libs-1.4.2-9.fc8 has been submitted as an update for Fedora 8

Comment 8 Fedora Update System 2008-05-31 02:10:11 UTC
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

Comment 9 Jason Vas Dias 2008-05-31 03:11:32 UTC
Yes, this is fixed now. Thank you!

Comment 10 Fedora Update System 2008-06-14 04:15:01 UTC
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.

Comment 11 Fedora Update System 2008-06-14 04:16:36 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.