This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 737223 - gl applications (using libGL.so) crash with glibc-2.14.90-8 when using proprietary NVIDIA driver
gl applications (using libGL.so) crash with glibc-2.14.90-8 when using propri...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
16
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Andreas Schwab
Fedora Extras Quality Assurance
:
: 742714 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-09 21:32 EDT by sangu
Modified: 2013-12-13 06:29 EST (History)
32 users (show)

See Also:
Fixed In Version: glibc-2.14.90-12.999
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-10-19 00:34:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 286388 None None None Never

  None (edit)
Description sangu 2011-09-09 21:32:58 EDT
Description of problem:
$ glxinfo
Segmentation fault

$ dmesg | grep libGL
[   21.294937] gnome-shell[1470]: segfault at ffffffffff700120 ip 00007f0c083b921b sp 00007fff6f38d240 error 4 in libGL.so.280.13[7f0c0831e000+c1000]
[   38.695713] gnome-session-c[1653]: segfault at ffffffffff700120 ip 00007f5467d9d21b sp 00007fffa5f83a60 error 4 in libGL.so.280.13[7f5467d02000+c1000]
[   42.351510] gnome-shell[1688]: segfault at ffffffffff700120 ip 00007f841378b21b sp 00007fffc886c610 error 4 in libGL.so.280.13[7f84136f0000+c1000]
[   52.520429] gnome-session-c[1816]: segfault at ffffffffff700120 ip 00007fcec274c21b sp 00007fff0d6f8d10 error 4 in libGL.so.280.13[7fcec26b1000+c1000]
[   55.454399] gnome-shell[1853]: segfault at ffffffffff700120 ip 00007f28ca14c21b sp 00007fff72741740 error 4 in libGL.so.280.13[7f28ca0b1000+c1000]
[   58.984598] gnome-shell[1919]: segfault at ffffffffff700120 ip 00007f3bbb89c21b sp 00007fff7de289d0 error 4 in libGL.so.280.13[7f3bbb801000+c1000]
[  224.619522] gnome-shell[2056]: segfault at ffffffffff700120 ip 00007f2ec04ef21b sp 00007fff27153410 error 4 in libGL.so.280.13[7f2ec0454000+c1000]
[  595.765828] gnome-shell[2254]: segfault at ffffffffff700120 ip 00007ff78c6bf21b sp 00007fff84efec70 error 4 in libGL.so.280.13[7ff78c624000+c1000]
[ 1297.738958] glxgears[3603]: segfault at ffffffffff700120 ip 00007f1a8c0b621b sp 00007fff443f2da0 error 4 in libGL.so.280.13[7f1a8c01b000+c1000]

Then, using gdb glxinfo works well.

Version-Release number of selected component (if applicable):
2.14.90-8.x86_64

How reproducible:
always

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
GL applications works well in glibc-2.14.90-4.x86_64.
nvidia  280.13 closed source driver.
Comment 1 sangu 2011-09-12 03:32:35 EDT
hmm, current   I uses nvidia closed drvier.
Then, why is mesa bug?


-----
xorg-x11-drv-nvidia-280.13-1.fc15.x86_64
mesa-libGL-7.11-4.fc16.x86_64
glibc-2.14.90-8.x86_64
Comment 2 sangu 2011-09-12 03:43:21 EDT
in glibc-2.14.90-8

$ ldd -r /usr/bin/glxinfo
	linux-vdso.so.1 (0x00007fff29fff000)
	libGLEW.so.1.6 => /usr/lib64/libGLEW.so.1.6 (0x00007f9532dba000)
	libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00007f9532b4d000)
	libGL.so.1 => /usr/lib64/nvidia/libGL.so.1 (0x00007f953283b000)
	[...]
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f952ed00000)
/usr/bin/ldd: line 118: 11509 Segmentation fault      
LD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= "$@"

$ ldd -r /usr/bin/gedit
[skip]
	/lib64/ld-linux-x86-64.so.2 (0x00007f6e4a478000)
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f6e42e9e000)
/usr/bin/ldd: line 118: 11564 Segmentation fault      LD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= "$@"
Comment 3 Adam Jackson 2011-09-12 10:23:55 EDT
Reassigning back to glibc.  If this isn't a glibc bug, then it's NOTOURBUG, since the reporter is not using Mesa's libGL.
Comment 4 Jiri Moskovcak 2011-09-12 15:53:54 EDT
I can confirm that removing xorg-x11-drv-nvidia-libs fixes the crash. Also downgrading to glibc from F15 fixes it.
Comment 5 Adam Williamson 2011-09-12 18:11:54 EDT
marking as CommonBugs, if we ship F16 Beta like this, lots of people are likely to hit it, so we should document it...
Comment 6 nobody 2011-09-22 12:24:34 EDT
I switched to nouveau and it still segfaults.  2.14.90-9 doesn't work.
Comment 7 Jiri Moskovcak 2011-09-22 12:35:08 EDT
(In reply to comment #6)
> I switched to nouveau and it still segfaults.  2.14.90-9 doesn't work.

just "switching" doesn't help, you need to remove the NVIDIA libs from the system - at least that's what worked for me.
Comment 8 Adam Williamson 2011-09-22 16:25:12 EDT
right, 'switching' from nvidia to nouveau is a somewhat complex operation, as the NVIDIA drivers replace the system's GL libs.

RPM Fusion's NVIDIA page has a section on it - http://rpmfusion.org/Howto/nVidia#head-3fe8fc42e24a89aff36645e27644b1f6445a9ee6 , "Disable or uninstall the nvidia driver".
Comment 9 Vaclav "sHINOBI" Misek 2011-09-29 14:29:19 EDT
Last working for me is glibc-2.14.90-4, the newer including glibc-2.14.90-10 segfaults.
Comment 10 Adam Williamson 2011-10-03 14:54:11 EDT
*** Bug 742714 has been marked as a duplicate of this bug. ***
Comment 11 Adam Williamson 2011-10-03 14:54:55 EDT
From the dupe:

Reverting this patch in glibc-2.14.90-5 also fixes crash
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=73d7af4f4c2b394063cb0b3a33ee2b00b5ad80b4
Comment 12 Vallimar 2011-10-04 19:46:46 EDT
After many tests and various builds, I have traced the regression to one specific change. From the original patch, lined above, it is this:
     --- a/elf/rtld.c
     +++ b/elf/rtld.c
     @@ -1391,7 +1391,7 @@
                   char *copy = malloc (len);
                   if (copy == NULL)
                     _dl_fatal_printf ("out of memory\n");
     -             l->l_libname->name = memcpy (copy, dsoname, len);
     +             l->l_name = l->l_libname->name = memcpy (copy, dsoname, len);
                 }
 
               /* Add the vDSO to the object list.  */

This change, gets later changed again to read:
     l->l_libname->name = l->l_name = memcpy (copy, dsoname, len);

I do not know which line is supposed to be correct, but when I revert
back to "l->l_libname->name = memcpy (copy, dsoname, len);" the problem
goes away. This is true for the latest version: glibc-2.14.90-10

I believe the reason this affects nvidia's libGL is because of a failed
symbol lookup. Doing "LD_DEBUG=version glxgears" for example, you can
see that it immediately terminates after a failure to lookup a symbol:

     glxgears: error: symbol lookup error: undefined symbol: pthread_key_create, version GLIBC_2.2.5 (fatal)

I'm not entirely sure what the relation is, though the comment at this
section makes specifies that l_name should not be set there. I assume
this being improperly set with the wrong info at this location causes
the error when it is attempted to be used later.
Comment 13 Vallimar 2011-10-04 19:48:25 EDT
This is the patch I used to correct the problem:


diff -up a/elf/rtld.c.rev b/elf/rtld.c
--- a/elf/rtld.c.rev    2011-10-04 09:59:59.764255345 -0400
+++ b/elf/rtld.c        2011-10-04 10:01:16.121628974 -0400
@@ -1397,7 +1397,7 @@ of this helper program; chances are you
              char *copy = malloc (len);
              if (copy == NULL)
                _dl_fatal_printf ("out of memory\n");
-             l->l_libname->name = l->l_name = memcpy (copy, dsoname, len);
+             l->l_libname->name = memcpy (copy, dsoname, len);
            }

          /* Add the vDSO to the object list.  */
Comment 14 Derek Linz 2011-10-04 22:29:01 EDT
Thank you! Vallimar's patch fixes it for me.
Comment 15 nucleo 2011-10-05 15:32:14 EDT
So can Vallimar's patch be applied in glibc upstream?
Comment 16 Dirk Nehring 2011-10-06 04:58:03 EDT
I downgraded the glibc to


http://koji.fedoraproject.org/scratch/nucleo/task_3396071/

and it works for me. But now the virt-manager does not work anymore:


[root@poseidon ~]# virt-manager 
Traceback (most recent call last):
  File "/usr/share/virt-manager/virt-manager.py", line 383, in <module>
    main()
  File "/usr/share/virt-manager/virt-manager.py", line 246, in main
    from virtManager import cli
  File "/usr/share/virt-manager/virtManager/cli.py", line 29, in <module>
    import libvirt
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 25, in <module>
    raise lib_e
ImportError: /usr/lib64/libvirt.so.0: symbol __fdelt_chk, version GLIBC_2.15 not defined in file libc.so.6 with link time reference
Comment 17 nucleo 2011-10-06 07:15:29 EDT
(In reply to comment #16)
> not defined in file libc.so.6 with link time reference

Try this scratch build with Vallimar's:

http://kojipkgs.fedoraproject.org/scratch/nucleo/task_3409171/
Comment 18 Dirk Nehring 2011-10-06 09:45:28 EDT
OK, with these RPMS everything seems to work.(In reply to comment #17)
> (In reply to comment #16)
> > not defined in file libc.so.6 with link time reference
> 
> Try this scratch build with Vallimar's:
> 
> http://kojipkgs.fedoraproject.org/scratch/nucleo/task_3409171/

OK, with this build everything seems to work.
Comment 19 Dirk Nehring 2011-10-06 09:47:43 EDT
FYI: Fedora 16/64 bit, NVidia 285.05.09 x86_64, all updates applied.
Comment 20 Adam Williamson 2011-10-06 17:19:24 EDT
2.14.90-5 is heavily broken, do not use that build.

vallimar's build is probably the best thing to go with as a workaround.
Comment 21 Gireesh Sreekantan 2011-10-07 17:58:08 EDT
vallimar's build works for me. I had the same bug (sample dmesg output)

111.907222] gnome-control-c[2611]: segfault at ffffffffff700120 ip 00007f1356da90fb sp 00007fff60ab44c0 error 4 in libGL.so.285.05.09[7f1356d0d000+c2000]

I wasn't able to open mplayer, vlc, gnome control center etc. KDE would never allow me to login.

After using vallimar's glibc (rpm --force) I am able to login to KDE and mplayer, vlc etc work as usual.
Comment 22 infinality 2011-10-08 23:34:34 EDT
Same problem here.  Vallimar's build worked for me too.
Comment 23 Magnus Tuominen 2011-10-09 00:37:10 EDT
Another praise for Vallimars build from me.
Comment 24 Tore H. Larsen 2011-10-09 17:50:16 EDT
cc
Comment 25 foxkyy 2011-10-10 14:40:30 EDT
I'm sort of new to this: how do I apply Vallimar's build?
Comment 26 infinality 2011-10-10 19:15:26 EDT
(In reply to comment #25)
> I'm sort of new to this: how do I apply Vallimar's build?

Download the packages for your arch (386 or x86_64) into a directory.  cd into the directory and run:

sudo rpm -Uvh --force --replacepkgs *.rpm

You'll need to log out and/or reboot afterwards.  Good luck.
Comment 27 foxkyy 2011-10-10 20:53:22 EDT
(In reply to comment #26)
> (In reply to comment #25)
> > I'm sort of new to this: how do I apply Vallimar's build?
> 
> Download the packages for your arch (386 or x86_64) into a directory.  cd into
> the directory and run:
> 
> sudo rpm -Uvh --force --replacepkgs *.rpm
> 
> You'll need to log out and/or reboot afterwards.  Good luck.

I tried that and this happened: error: Failed dependencies:
	kernel-headers is needed by glibc-headers-2.14.90-10.i686
	kernel-headers >= 2.2.1 is needed by glibc-headers-2.14.90-10.i686

Where do I get the dependencies?
Comment 28 nucleo 2011-10-10 21:03:12 EDT
(In reply to comment #25)
> I'm sort of new to this: how do I apply Vallimar's build?

Try to install with yum from here
http://nucleo.fedorapeople.org/glibc/

I added .1 to release so it should just update installed glibc.
Comment 29 infinality 2011-10-10 21:27:37 EDT
(In reply to comment #27)
> (In reply to comment #26)
> > (In reply to comment #25)
> > > I'm sort of new to this: how do I apply Vallimar's build?
> > 
> > Download the packages for your arch (386 or x86_64) into a directory.  cd into
> > the directory and run:
> > 
> > sudo rpm -Uvh --force --replacepkgs *.rpm
> > 
> > You'll need to log out and/or reboot afterwards.  Good luck.
> 
> I tried that and this happened: error: Failed dependencies:
>  kernel-headers is needed by glibc-headers-2.14.90-10.i686
>  kernel-headers >= 2.2.1 is needed by glibc-headers-2.14.90-10.i686
> 
> Where do I get the dependencies?

yum install kernel-headers
Comment 30 Joel Kirchmeyer 2011-10-10 21:36:31 EDT
Instead of the rpm command I recommend yum reinstall ./glibc-2.14.90-10.x86_64.rpm that way yum won't complain about the rpmdb being altered outside of yum.
Comment 31 Fedora Update System 2011-10-11 09:17:44 EDT
glibc-2.14.90-11 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/glibc-2.14.90-11
Comment 32 nucleo 2011-10-12 11:56:00 EDT
(In reply to comment #31)
> glibc-2.14.90-11 has been submitted as an update for Fedora 16.
> https://admin.fedoraproject.org/updates/glibc-2.14.90-11

This build uses Valdemar's patch and fixes problem with NVIDIA driver.

But this update broke user groups.
I added user in groupsh such as mock wireshark and other and after this update id shows only user groups 500 (but user is still listed in all groups in /tec/group).
This is not because of Valdemar's patch because no such problem in glibc-2.14.90-10 built with this patch.
Comment 33 Fedora Update System 2011-10-12 12:49:25 EDT
Package glibc-2.14.90-11:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.14.90-11'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-14175
then log in and leave karma (feedback).
Comment 34 Fedora Update System 2011-10-18 04:10:42 EDT
glibc-2.14.90-12.999 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/FEDORA-2011-14504
Comment 35 Fedora Update System 2011-10-19 00:34:21 EDT
glibc-2.14.90-12.999 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 36 Adam Williamson 2011-11-07 23:37:04 EST

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 37 Gabor Papp 2011-12-05 05:11:20 EST
I seem to be having this or a very similar issue on i686 F16 with xorg-x11-drv-nvidia-libs-290.10-1.fc16.i686 and glibc-2.14.90-19.i686, glibc-2.14.90-21.i686.

Various programs like firefox, nvidia-settings, chrome, nautilus crash on two different computers. This is a backtrace from a nautilus crash:

Program received signal SIGSEGV, Segmentation fault.
0x0011cdb4 in _dl_relocate_object () from /lib/ld-linux.so.2
(gdb) backtrace
#0  0x0011cdb4 in _dl_relocate_object () from /lib/ld-linux.so.2
#1  0x001243ab in dl_open_worker () from /lib/ld-linux.so.2
#2  0x0011fd0f in _dl_catch_error () from /lib/ld-linux.so.2
#3  0x00123d06 in _dl_open () from /lib/ld-linux.so.2
#4  0x00330c09 in dlopen_doit () from /lib/libdl.so.2
#5  0x0011fd0f in _dl_catch_error () from /lib/ld-linux.so.2
#6  0x003313ba in _dlerror_run () from /lib/libdl.so.2
#7  0x00330cb7 in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2
#8  0x45333354 in g_module_open () from /lib/libgmodule-2.0.so.0
#9  0x081271dc in ?? ()
#10 0x4530ca49 in g_type_module_use () from /lib/libgobject-2.0.so.0
#11 0x08127539 in ?? ()
#12 0x0806872a in ?? ()
#13 0x452e6c14 in g_cclosure_marshal_VOID__VOID ()
   from /lib/libgobject-2.0.so.0
#14 0x452e403e in ?? () from /lib/libgobject-2.0.so.0
#15 0x452e5645 in g_closure_invoke () from /lib/libgobject-2.0.so.0
#16 0x452f86a8 in ?? () from /lib/libgobject-2.0.so.0
#17 0x453012ff in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#18 0x45301464 in g_signal_emit () from /lib/libgobject-2.0.so.0
#19 0x453cdee6 in g_application_register () from /lib/libgio-2.0.so.0
#20 0x08068465 in ?? ()
#21 0x453ce4bd in g_application_run () from /lib/libgio-2.0.so.0

dmesg:
[ 1909.469578] nautilus[2627]: segfault at bb6b9315 ip 00ba7db4 sp bfd28440 error 6 in ld-2.14.90.so[b9b000+21000]

the programs start up fine when run like this:
LD_PRELOAD=/usr/lib/libGL.so.1 nautilus
Comment 38 Tom Shield 2012-01-02 11:09:23 EST
I have the identical problem to the previous post with glibc-2.14.90-24.fc16.4.i686 and Rpmfusion rpms for the Nvidia driver (listed below), and the solution:

LD_PRELOAD=/usr/lib/libGL.so nautilus

allows nautilus to run with no problems.

I just did this install yesterday, so I don't have any history of the problem with previous versions of glibc.

Here is nautilus run inside gdb:

(gdb) run
Starting program: /usr/bin/nautilus 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
[New Thread 0xb7dd4b40 (LWP 4220)]
[New Thread 0xb73ffb40 (LWP 4221)]
[New Thread 0xb69ffb40 (LWP 4222)]

Program received signal SIGSEGV, Segmentation fault.
elf_dynamic_do_Rela (skip_ifunc=0, nrelative=558093, relsize=6782952, 
    reladdr=<optimized out>, map=0x8292660, lazy=<optimized out>)
    at do-rel.h:121

(gdb) bt
#0  elf_dynamic_do_Rela (skip_ifunc=0, nrelative=558093, relsize=6782952, 
    reladdr=<optimized out>, map=0x8292660, lazy=<optimized out>)
    at do-rel.h:121
#1  _dl_relocate_object (scope=0x8292818, reloc_mode=1, consider_profiling=0)
    at dl-reloc.c:265
#2  0x4b9353ab in dl_open_worker (a=0xbfffe8c0) at dl-open.c:338
#3  0x4b930d0f in _dl_catch_error (objname=0xbfffe8e4, errstring=0xbfffe8e8, 
    mallocedp=0xbfffe8ef, operate=0x4b935100 <dl_open_worker>, args=0xbfffe8c0)
    at dl-error.c:178
#4  0x4b934d06 in _dl_open (file=
    0x82a0df0 "/usr/lib/nautilus/extensions-3.0/libtotem-properties-page.so", 
    mode=-2147483647, caller_dlopen=0x4c61f354, nsid=-2, argc=1, argv=
    0xbffff1c4, env=0xbffff1cc) at dl-open.c:575
#5  0x4baf4c09 in dlopen_doit (a=0xbfffea90) at dlopen.c:67
#6  0x4b930d0f in _dl_catch_error (objname=0x81d5c34, errstring=0x81d5c38, 
    mallocedp=0x81d5c30, operate=0x4baf4b70 <dlopen_doit>, args=0xbfffea90)
    at dl-error.c:178
#7  0x4baf53ba in _dlerror_run (operate=0x4baf4b70 <dlopen_doit>, args=
    0xbfffea90) at dlerror.c:164
#8  0x4baf4cb7 in __dlopen (file=
    0x82a0df0 "/usr/lib/nautilus/extensions-3.0/libtotem-properties-page.so", 
    mode=1) at dlopen.c:88
#9  0x4c61f354 in _g_module_open (bind_local=1, bind_lazy=1, file_name=
    0x82a0df0 "/usr/lib/nautilus/extensions-3.0/libtotem-properties-page.so")
    at gmodule-dl.c:99
#10 g_module_open (file_name=
    0x82a0da8 "/usr/lib/nautilus/extensions-3.0/libtotem-properties-page.so", 
    flags=G_MODULE_BIND_MASK) at gmodule.c:439
#11 0x081271dc in nautilus_module_load (gmodule=0x820b550 [NautilusModule])
    at nautilus-module.c:85
#12 0x4bf93a49 in g_type_module_use (module=0x820b550 [NautilusModule])
    at gtypemodule.c:256
#13 0x08127539 in nautilus_module_load_file (filename=
    0x821b1e0 "/usr/lib/nautilus/extensions-3.0/libtotem-properties-page.so")
    at nautilus-module.c:195
#14 load_module_dir (dirname=0x817788c "/usr/lib/nautilus/extensions-3.0")
    at nautilus-module.c:222
...


[root@taylor ~]# rpm -qa | grep glibc
glibc-debuginfo-common-2.14.90-24.fc16.4.i686
glibc-2.14.90-24.fc16.4.i686
glibc-debuginfo-2.14.90-24.fc16.4.i686
glibc-common-2.14.90-24.fc16.4.i686
glibc-devel-2.14.90-24.fc16.4.i686
glibc-headers-2.14.90-24.fc16.4.i686

[root@taylor ~]# rpm -qa | grep nvidia
xorg-x11-drv-nvidia-290.10-1.fc16.i686
nvidia-settings-1.0-13.fc16.i686
xorg-x11-drv-nvidia-libs-290.10-1.fc16.i686
nvidia-xconfig-1.0-11.fc16.i686
kmod-nvidia-3.1.6-1.fc16.i686.PAE-290.10-1.fc16.6.i686
kmod-nvidia-PAE-290.10-1.fc16.6.i686

[root@taylor ~]# uname -a
Linux taylor.aem.umn.edu 3.1.6-1.fc16.i686.PAE #1 SMP Wed Dec 21 23:01:09 UTC 2011 i686 i686 i386 GNU/Linux
Comment 39 Gabor Papp 2012-01-02 11:32:37 EST
rebuilding the prelink database solved it for me. at least until the next nvidia driver update:

prelink -ua
rm /etc/prelink.cache
cd to /etc/cron.daily and execute the prelink script
Comment 40 Tom Shield 2012-01-02 13:05:04 EST
rebuilding the prelink database worked for me too.  Many thanks.
Comment 41 Amit Saha 2012-03-29 09:16:51 EDT
Rebuilding the prelink database seems to solve the issue for me. Fedora 16 32-bit (proprietary nVidia drivers)
Comment 42 salsaman 2012-06-09 09:00:26 EDT
I had a similar problem running 32 bit programs on a 64 bit system, after upgrading from fedora 16 to fedora 17.

The problem was resolved by rebuilding the prelink database, but only after banging my head against the wall several times until I found this post.

Might I suggest that you make this a part of the upgrade scripts in future ?

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