gdk-pixbuf2-2.40.0-5.sgug trigger error gdk-pixbuf-query-loaders

[mgtremaine]

The triggerin and triggerpostun in the SPEC file fail on an O2 and Indigo2 (as reported on the SGUG forum)

The failure is the update cache.

[sgugshell root@saiph /]# gdk-pixbuf-query-loaders --update-cache
Bus error (core dumped)

-Mike

[danielhams]

Hello - thank you for your report.

This is a little strange.

When possible can you please provide:

1. the output of rpm -qa |grep rpm-libs
2. the output of the following as a user not as root:

[user@saiph ~] sgugshell
[sgugshell user@saiph ~] sudo rpm -vvv --reinstall -ivh /path/to/RPMS/mips/gdk-pixbuf2-*.rpm

And we see if anything obvious crops up.

[danielhams]

(If anyone else gets the zen to look at this - originally I believe we'd fixed these trigger coredumps in a46f00e - which should be in 0.0.7 - but we'll have to see since it's not clear the real root cause yet).

[mgtremaine]

1. [sgugshell root@saiph /]# rpm -qa |grep rpm-libs
   rpm-libs-4.15.0-19.sgug.mips

2. There was like 3000 lines of output so I just left it here
   https://www.stellarcore.net/downloads/sgi/sgug_gdk_rpm_out.txt

-Mike

[danielhams]

Great thanks for your patience -> I see I am an idiot and assumed the wrong thing (rpm crash) - even though you told me it was gdk-pixbuf-query-loaders too ! Acknowledged + apologies.

The log confirms at least that RPM is installing as intended - now I am up to speed :-)

I guess we'll need to rebuild gdk-pixbuf2 in debug non-strippped and then re-run as you demonstrated and let it core dump, then use gdb to obtain a stack trace.

(Goes to rebuild 'gdk-pixbuf2' in debug)

Install this with:

[sgugshell user@host ~] sudo rpm -Uvh /path/to/extracted/*.rpm

Then re-run manually like you did in original report - and let it coredump.
You (hopefully) can then obtain a stack trace with:

gdb /usr/sgug/bin/gdk-pixbuf-query-loaders core
where

Perhaps other useful info might be the output from:

par -i /usr/sgug/bin/gdk-pixbuf-query-loaders --update-cache 1>/tmp/gdkpbpar.log 2>&1

Thank you!

[mgtremaine]

GDB with symbols:

[sgugshell root@saiph /]# gdb /usr/sgug/bin/gdk-pixbuf-query-loaders core
GNU gdb (GDB) 7.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mips-sgi-irix6.5".
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/sgug/bin/gdk-pixbuf-query-loaders...done.
Core was generated by `gdk-pixbuf-query-loaders'.
Program terminated with signal 10, Bus error.
#0 __derived_to_base_conversion () at /j10/mtibuild/v741m/workarea/v7.4.1m/libC/lang_support/rtti.cxx:85
85 /j10/mtibuild/v741m/workarea/v7.4.1m/libC/lang_support/rtti.cxx: No such file or directory.
(gdb) bt
#0 __derived_to_base_conversion () at /j10/mtibuild/v741m/workarea/v7.4.1m/libC/lang_support/rtti.cxx:85
#1 0x0adb641c in __dynamic_cast () at /j10/mtibuild/v741m/workarea/v7.4.1m/libC/lang_support/rtti.cxx:281
#2 0x04d14f14 in std::has_facet<std::ctype > (__loc=...)
at /usr/people/dan/rpmbuild/BUILD/gcc-9.2.0-20190812/obj-mips-sgi-irix6.5/mips-sgi-irix6.5/libstdc++-v3/include/bits/locale_classes.tcc:104
#3 0x04d019a4 in std::basic_ios<char, std::char_traits >::_M_cache_locale (this=0x4dee07c, __loc=...)
at /usr/people/dan/rpmbuild/BUILD/gcc-9.2.0-20190812/obj-mips-sgi-irix6.5/mips-sgi-irix6.5/libstdc++-v3/include/bits/basic_ios.tcc:157
#4 0x04d01ec0 in std::basic_ios<char, std::char_traits >::init (this=0x4dee07c, __sb=0x4dedce8)
at /usr/people/dan/rpmbuild/BUILD/gcc-9.2.0-20190812/obj-mips-sgi-irix6.5/mips-sgi-irix6.5/libstdc++-v3/include/bits/basic_ios.tcc:126
#5 0x04c7d100 in basic_ostream (__sb=, this=, __in_chrg=, __vtt_parm=)
at /usr/people/dan/rpmbuild/BUILD/gcc-9.2.0-20190812/libstdc++-v3/libsupc++/new:174
#6 Init (this=) at ../../../../../libstdc++-v3/src/c++98/ios_init.cc:91
#7 std::ios_base::Init::Init (this=) at ../../../../../libstdc++-v3/src/c++98/ios_init.cc:78
#8 0x0f981810 in _GLOBAL__sub_I_module_manager.cpp () from /usr/sgug/lib32/libmodman.so.1
#9 0x0f9865c0 in __do_global_ctors_aux () from /usr/sgug/lib32/libmodman.so.1
#10 0x0f986644 in ?? () from /usr/sgug/lib32/libmodman.so.1
warning: GDB can't find the start of the function at 0xf986642.

GDB is unable to find the start of the function at 0xf986642

and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
This problem is most likely caused by an invalid program counter or
stack pointer.
However, if you think GDB should simply search farther back
from 0xf986642 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.

OUTPUT for par here
https://www.stellarcore.net/downloads/sgi/gdkpbpar.log

-Mike

[danielhams]

Thank you for getting the trace - I think we have a good picture of what's going on (although why only certain machines hit it is a little head scratchy!).

Reading the stack trace from bottom to top - we see the following:

warning: GDB can't find the start of the function at 0xf986642.

This is because our gdb has issues working out the root of stack frames for pthreaded applications. We have to work with this for now.

#9 0x0f9865c0 in __do_global_ctors_aux () from /usr/sgug/lib32/libmodman.so.1
#8 0x0f981810 in _GLOBAL__sub_I_module_manager.cpp () from /usr/sgug/lib32/libmodman.so.1
#7 std::ios_base::Init::Init (this=) at ../../../../../libstdc++-v3/src/c++98/ios_init.cc:78

Looks like the binary uses/is linked to libmodman and as such is pulling in libstdc++ from GCC - we can assume it's C++ at this point. Fast forward a bit up the trace

#2 0x04d14f14 in std::has_facet<std::ctype > (__loc=...)
at /usr/people/dan/rpmbuild/BUILD/gcc-9.2.0-20190812/obj-mips-sgi-irix6.5/mips-sgi-irix6.5/libstdc++-v3/include/bits/locale_classes.tcc:104
#1 0x0adb641c in __dynamic_cast () at /j10/mtibuild/v741m/workarea/v7.4.1m/libC/lang_support/rtti.cxx:281
#0 __derived_to_base_conversion () at /j10/mtibuild/v741m/workarea/v7.4.1m/libC/lang_support/rtti.cxx:85

Ah - here's the problem - something has pulled in the IRIX C++ shared library - and now the binary is mixing and matching between libstdc++ and MIPSPro C++ libraries - no surprise this doesn't work out well.

How can this happen - well in 0.0.7beta there is native file monitoring as a module in glib2 - the specific RPM is glib2-fam. This library makes use of IRIX libfam - which needs the MIPSPro C++ library.

If you just want to see if this makes a difference, you can uninstall glib2-fam (and anything depending on it) - and then reexecute the problematic command. You can always re-install the missing modules afterwards.

There wasn't time to fix this in 0.0.7beta unfortunately, but it has been fixed since then to avoid any linking to the MIPSPro C++ lib.

If you are willing + up to it, you can try to rpmbuild yourself new versions of sgug-fam and glib2 from our wipnonautomated branch. Otherwise you can wait a little bit while I build up a patch ball to perform the bug fix / upgrade -> we'll need a bug fix / patch for this anyway.

[mgtremaine]

Ok let's do this..

Step 1) Remove glib2-fam
[sgugshell root@saiph /]# rpm -e --nodeps glib2-fam

Test

[sgugshell root@saiph /]# gdk-pixbuf-query-loaders --update-cache
[sgugshell root@saiph /]#

No Core Dump.. Looks good

I'll look at building the WIP version of the fam's and see how that goes.

-Mike

ADDED: gtk3-demo now runs fine and pidgin starts up as expected.