From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020408 Description of problem: Almost all programs needing root authentication segfault when started from non-privileged user. In 7.2 those programs asked for the root password when run; in 7.3 they segfault: $ firewall-config Segmentation fault $ gdmconfig Segmentation fault $ redhat-config-users Segmentation fault $ serviceconf Segmentation fault They run well, when started from root, though Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: (see above) Expected Results: The root password should be asked; no segfault Additional info:
What is the output of "rpm -qV usermode usermode-gtk pam glibc serviceconf"? I'm not seeing this on my system....
# rpm -qV usermode usermode-gtk pam glibc serviceconf usermode-1.53-2 usermode-gtk-1.53-2 pam-0.75-32 glibc-2.2.5-34 serviceconf-0.7.0-3
What are the contents of /etc/sysconfig/i18n? What is the output of "id -a" when run as this user?
$ cat /etc/sysconfig/i18n LANG="en_US" SUPPORTED="en_US:en" SYSFONT="lat0-sun16" SYSFONTACM="iso01" $ id -a uid=500(udippel) gid=500(udippel) groups=500(udippel)
Looks fine from here -- those don't appear to cause any strange behavior here. Does it still segfault if you run "ulimit -c unlimited; /usr/sbin/userhelper -t -w serviceconf"? If so, can you obtain a backtrace by becoming root, starting "gdb /usr/sbin/userhelper core", and giving it the "bt" command?
ulimit -c unlimited; /usr/sbin/userhelper -t -w serviceconf ends up in working nicely here!! (no segfault) What now?
Try removing usermode-gtk, then launching serviceconf from a terminal window. If that succeeds, re-install the usermode-gtk package, copy /usr/bin/consolehelper to /tmp/serviceconf, and try running /tmp/serviceconf under a debugger: gdb /tmp/serviceconf run If you still get a segmentation fault, you should be ablt to obtain a backtrace by using the "bt" command.
Try removing usermode-gtk => done launching serviceconf from a terminal window => succeeds If that succeeds [...] try running /tmp/serviceconf under a debugger: gdb /tmp/serviceconf run => result: "Starting program: /tmp/serviceconf (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program received signal SIGTRAP, Trace/breakpoint trap. 0x40000b50 in _start () from /lib/ld-linux.so.2 (gdb)" Though I definitively have no clue what I'm doing here, I hope it helps!
Darn. The binaries are stripped of debugging information. Please install the latest builds (where /usr/bin/consolehelper isn't stripped) from http://people.redhat.com/nalin/test/, and see if the debugger gives you a good backtrace. If you get a SIGTRAP in the debugger, tell it to continue with the "c" command until you get a SIGSEGV, which will be the point where it actually crashes. A backtrace at that point should pinpoint the location where it fails.
Program received signal SIGSEGV, Segmentation fault. 0x4033efbc in gdk_window_get_geometry () from /usr/X11R6/lib/libXft.so.1 (gdb) c Is this better??
Forgot the bt. Here's the whole set: Program received signal SIGSEGV, Segmentation fault. 0x4033efbc in gdk_window_get_geometry () from /usr/X11R6/lib/libXft.so.1 (gdb) bt #0 0x4033efbc in gdk_window_get_geometry () from /usr/X11R6/lib/libXft.so.1 #1 0x405f149a in ?? () #2 0x405f214d in ?? () #3 0x405ddd2d in ?? () #4 0x40016f91 in real_gdk_init_check () from /usr/lib/libgdkxft.so.0 #5 0x40016038 in gdk_init_check () from /usr/lib/libgdkxft.so.0 #6 0x400fad06 in gtk_init_check () from /usr/lib/libgtk-1.2.so.0 #7 0x08049cbf in ?? () #8 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6
This is very confusing. The consolehelper binary isn't even linked with libgtk-1.2 -- it's a GTK2 program, so it's linked with libgtk-x11-2.0. Please verify this by running 'ldd /usr/bin/consolehelper-gtk | grep gtk' and verifying that the gtk2 package is installed correctly by running 'rpm -V gtk2 XFree86-libs'. Because the segfault appears to be occurring when consolehelper-gtk attempts to connect to the X display, could you list the contents of the $DISPLAY environment variable? If it's ":0.0" or something similar, please also run "ls -l /tmp/.X11-unix" to verify that there aren't any strange problems with the permissions on the listening socket.
Are you using the GdkXft hack? If so, please remove it.
Oh yes, you caught me on that one. Honestly, I didn't think of it! and only remembered when you asked. So, how to downgrade to 7.2, because with 7.2 this one was fine and especially increased the quality of the display for me; and it is even legal where I live! I didn't get your previous comment fully: should I still go on or do we close the whole matter by stating that the nice GdkXft hack does not work together with 7.3 ??
My understanding of GdkXft is that it causes the GTK 1.2 libraries to be loaded. Because it contains many symbols with the same names as those included in GTK 2 (such as gdk_window_get_geometry) but which have changed in a binary-incompatible way, you get a mixture of symbols from one version or the other, which causes programs to crash. GTK2 itself already provides anti-aliased fonts if you set the environment variable GDK_USE_XFT to "1" (in your .bashrc or .cshrc), so such a hack is unnecessary with newer programs. If you must keep GdkXft installed, you can also downgrade the usermode package to the version included with RHL 7.2, though as various other programs get ported to GTK2 (as usermode was for RHL 7.3), you'll continue to see crashes like this. I'm going to mark this bug as resolved and tag it as WONTFIX because renaming symbols in either library is not something we can do without breaking compatibility with applications already built against that library.