Bug 155820

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.