Bug 155820 - gtk2.i386 %post scripts segfault on x86_64
gtk2.i386 %post scripts segfault on x86_64
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks: FC4Blocker
  Show dependency treegraph
 
Reported: 2005-04-23 22:55 EDT by Michal Jaegermann
Modified: 2015-01-04 17:19 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-16 04:51:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2005-04-23 22:55:57 EDT
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
Comment 1 Matthias Clasen 2005-04-25 12:11:28 EDT
Works fine on a x86_64 rawhide box here. 
I will need a stacktrace to make any progress on this.
Comment 2 Matthias Clasen 2005-04-25 12:11:56 EDT
Please reopen from NEEDINFO if you attach a stacktrace
Comment 3 Michal Jaegermann 2005-04-25 14:04:12 EDT
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?
Comment 4 Matthias Clasen 2005-04-26 01:26:59 EDT
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 ?
Comment 5 Michal Jaegermann 2005-04-26 10:55:22 EDT
> 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.
Comment 6 Michal Jaegermann 2005-04-26 11:07:56 EDT
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.
Comment 7 Matthias Clasen 2005-04-26 11:15:09 EDT
Ok, moving to kernel then
Comment 8 Michal Jaegermann 2005-04-26 18:34:32 EDT
kernel-2.6.11-1.1267_FC4 does not change the picture.
Comment 9 Warren Togami 2005-04-27 05:15:10 EDT
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
Comment 10 Michal Jaegermann 2005-04-27 11:44:31 EDT
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.
Comment 11 Warren Togami 2005-05-16 04:51:41 EDT
I'm willing to bet this has been solved by the solution to Bug 155790.  REOPEN
if this happens with the latest FC4 kernels.

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