Red Hat Bugzilla – Bug 155820
gtk2.i386 %post scripts segfault on x86_64
Last modified: 2015-01-04 17:19:07 EST
Description of problem:
Postinstall scriplet from gtk2.i386 does this:
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
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
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):
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:
["/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:
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
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?
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.