Description of problem: Postinstall scriplet from gtk2.i386 does this: /sbin/ldconfig /usr/bin/update-gdk-pixbuf-loaders i386-redhat-linux /usr/bin/update-gtk-immodules i386-redhat-linux The problem is that the second line has the following effect: # /usr/bin/update-gdk-pixbuf-loaders i386-redhat-linux /usr/bin/update-gdk-pixbuf-loaders: line 22: 8638 Segmentation fault /usr/bin/gdk-pixbuf-query-loaders-32 >/etc/gtk-2.0/$host/gdk-pixbuf.loaders and as a side-effect leftovers from the previous version of gtk2 are also left on a system. This does not happen on x86 installation or if one does /usr/bin/update-gdk-pixbuf-loaders x86_64-redhat-linux as in gtk2.x86_64 postinstall scriplet. The following packages depend on gtk2.i386: GConf2 i386 2.10.0-2 installed 4.0 M evolution-data-server i386 1.2.2-2 installed 9.1 M gnome-vfs2 i386 2.10.0-3 installed 3.9 M libgcj i386 4.0.0-0.42 installed 26 M libgnome i386 2.10.0-2 installed 2.8 M libgsf i386 1.11.1-2 installed 156 k libwpd i386 0.8.0-4 installed 435 k openoffice.org-core i386 1:1.9.92-2 installed 186 M openoffice.org-impress i386 1:1.9.92-2 installed 4.2 M openoffice.org-math i386 1:1.9.92-2 installed 3.1 M openoffice.org-pyuno i386 1:1.9.92-2 installed 238 k openoffice.org-writer i386 1:1.9.92-2 installed 5.6 M so deinstalling it is not really a good option. Version-Release number of selected component (if applicable): gtk2-2.6.7-2 How reproducible: always
Works fine on a x86_64 rawhide box here. I will need a stacktrace to make any progress on this.
Please reopen from NEEDINFO if you attach a stacktrace
Hm, this seems to be a problem. As a quoted error message says this is /usr/bin/gdk-pixbuf-query-loaders-32 which segfaults. Running this under strace comes remarkably short: execve("/usr/bin/gdk-pixbuf-query-loaders-32", ["/usr/bin/gdk-pixbuf-query-loader"...], [/* 35 vars */]) = 0 brk(0) = 0x804b000 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ [ Process PID=3222 runs in 32 bit mode. ] An attempt to look at this with gdb makes gdb to print after 'run' Loaded system supplied DSO at 0xffffe000 and after that nothing. Looking at a process table one can find there something like that: root 3097 Ss 10:58 0:00 \_ bash root 3138 S 11:00 0:00 | \_ gdb /usr/bin/gdk-pixbuf-query-loaders-32 root 3141 R+ 11:00 1:54 | \_ /usr/bin/gdk-pixbuf-query-loaders-32 with 'strace -p 3138' printing 'wait4(-1,' and this call, not surprisingly, never finishing. A process 3141 is unkillable. I eventually ended up with sending to it all possible signals in a loop with no traces of a reaction. The only way to make it to go is to reboot and this gives a big trouble when unmounting file systems as most of everything is "busy". After SysRq-T one can find something of that sort: ..... <ffffffff8010f0de>{system_call+126} gdk-pixbuf-qu R running task 0 3141 3138 (NOTLB) gdb S ffffffff805027a0 0 3138 3097 3141 (NOTLB) ffff81000ca3fec8 0000000000000082 00007fffffcbb000 00007fffffcbaf7c 000000740ca3fea8 ffff810013dec0f0 ffff810013dec850 ffff810000000000 0000000000000c50 0000000000000012 Call Trace:<ffffffff8013fe19>{do_wait+3577} <ffffffff801355f0>{default_wake_function+0} <ffffffff8010f15f>{sysret_signal+20} <ffffffff8010f0de>{system_call+126} with no call trace for the proces in question. OTOH if one will do in gdb that: (gdb) b main Function "main" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (main) pending. and aftet that 'run' then sometimes a bunch of messages from various pixbuf loaders is printed and "program exited normally" but other times the picture is the same as above. When trying the same with /usr/bin/gtk-query-immodules-2.0-32, which also bombs, results look remarkably the same as above. If this does not pinpoint a source of the trouble then any other ideas where to look?
Hmm. Are the right loaders present in /usr/lib/gtk-2.0/2.4.0/loaders ? What does ldd /usr/bin/gdk-pixbuf-query-loaders report ?
> What does ldd /usr/bin/gdk-pixbuf-query-loaders report ? Not much, I am afraid. # ldd /usr/bin/gdk-pixbuf-query-loaders-32 /usr/bin/ldd: line 116: 3199 Segmentation fault LD_TRACE_LOADED_OBJECTS=1 LD_WARN= LD_BIND_NOW= LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= "$@" The problem is that "$@" expands to /usr/bin/gdk-pixbuf-query-loaders-32 and we are back where we were before. This is eval line which ends up with a status 139 (128+11, as expected). If you wonder if /usr/lib/gtk-2.0/2.4.0/loaders/ directory is properly populated then 'rpm -qVf /usr/lib/gtk-2.0/2.4.0/loaders/' does not complain about it and 'ls -l' reports: 12396 Apr 22 13:55 libpixbufloader-ani.so 12684 Apr 22 13:55 libpixbufloader-bmp.so 22668 Apr 22 13:55 libpixbufloader-gif.so 12600 Apr 22 13:55 libpixbufloader-ico.so 14348 Apr 22 13:55 libpixbufloader-jpeg.so 9308 Apr 22 13:55 libpixbufloader-pcx.so 15024 Apr 22 13:55 libpixbufloader-png.so 12008 Apr 22 13:55 libpixbufloader-pnm.so 6880 Apr 22 13:55 libpixbufloader-ras.so 12072 Apr 22 13:55 libpixbufloader-tga.so 10296 Apr 22 13:55 libpixbufloader-tiff.so 6432 Apr 22 13:55 libpixbufloader-wbmp.so 10040 Apr 22 13:55 libpixbufloader-xbm.so 32508 Apr 22 13:55 libpixbufloader-xpm.so 64-bit loaders are, obviously, in /usr/lib64/gtk-2.0/2.4.0/loaders/. Keep in mind that on few occasions I managed to run gdk-pixbuf-query-loaders-32 to normal completion; in gdb when I set a break in main(). The trouble is that I cannot do that consistently and never when running outside gdb.
I realized something. Yesterday people on fedora-test-list were complaining about random crashes in various programs after recent updates. I rebooted 2.6.11-1.1251_FC4 kernel and both /usr/bin/gdk-pixbuf-query-loaders-32 and /usr/bin/gtk-query-immodules-2.0-32 run without any problems. But if booted 2.6.11-1.1258_FC4 or 2.6.11-1.1261_FC4 I am seeing what is described above. It looks like that I am barking on a wrong tree.
Ok, moving to kernel then
kernel-2.6.11-1.1267_FC4 does not change the picture.
The above might be describing 2 or more different issues. x86_64 Random system deadlocks, spontatenous reboots or panics are Bug 155827 Bug 155790 are many 32-bit crashes on x86_64 Bug 155897 is kernel causing rpm trouble on x86_64
My guess would be that this is another manifestation of bug 155790. However running under gdb may help only if a breakpoint was set before doing "run" and even that is a gamble. Without setting a breakpoint gdb does not help.
I'm willing to bet this has been solved by the solution to Bug 155790. REOPEN if this happens with the latest FC4 kernels.