Re: i386 current upgrade and binary compatibility

[Sverre Froyen <sverre%viewmark.com@localhost>]

On Friday 28 March 2008, Sverre Froyen wrote:
> On Thursday 27 March 2008, Mark Davies wrote:
...
> >
> > Moving forward we need to either identify what the actual ABI change was
> > and reverse it or bump the version number of the library.
>
> OK. I have a new libstdc++ built with -g and all my old binaries.  What can
> I do to help track this down?
>
> Here's a backtrace example from artsd segfaulting:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xbb606906 in std::ostream::flush (this=0xbb676620)
>     at /usr/src/gnu/dist/gcc4/libstdc++-v3/include/bits/basic_ios.h:308
> 308           { return _M_streambuf; }
> Current language:  auto; currently c++
>
> #0  0xbb606906 in std::ostream::flush (this=0xbb676620)
>     at /usr/src/gnu/dist/gcc4/libstdc++-v3/include/bits/basic_ios.h:308
> #1  0xbb623b56 in sentry (this=0xbfbfdbeb, __in=@0xbfbfdc58,
> __noskip=false) at
> /usr/src/gnu/dist/gcc4/libstdc++-v3/include/bits/istream.tcc:58 #2 
> 0xbb642da5 in std::operator>><char, std::char_traits<char>,
> std::allocator<char> > (__in=@0xbfbfdc58, __str=@0xbfbfdee0)
>     at /usr/src/gnu/dist/gcc4/libstdc++-v3/src/istream.cc:277
> #3  0xbb91fe60 in Arts::MCOPConfig::readListEntry ()
>    from /usr/pkg/lib/libmcop.so.1
> #4  0xbb917649 in readPath () from /usr/pkg/lib/libmcop.so.1
> #5  0xbb9177c5 in Arts::MCOPUtils::traderPath ()
> from /usr/pkg/lib/libmcop.so.1
> #6  0xbb922676 in Arts::TraderHelper::load () from
> /usr/pkg/lib/libmcop.so.1 #7  0xbb922730 in
> Arts::TraderHelper::TraderHelper ()
>    from /usr/pkg/lib/libmcop.so.1
> #8  0xbb922778 in Arts::TraderHelper::the () from /usr/pkg/lib/libmcop.so.1
> #9  0xbb9239c8 in Arts::TraderQuery_impl::query ()
>    from /usr/pkg/lib/libmcop.so.1
> #10 0x08062d9b in Arts::SimpleSoundServer_impl::SimpleSoundServer_impl ()
> #11 0x0805b416 in Arts::SoundServerV2_impl::SoundServerV2_impl ()
> #12 0x0805d7b3 in SoundServerV2_impl_Factory::createInstance ()
> #13 0xbb90f87d in Arts::ObjectManager::create ()
> from /usr/pkg/lib/libmcop.so.1
> #14 0xbbbb8ebc in Arts::SoundServerV2_base::_create ()

The segentaion fault happens because  __in._M_tie is bogus (see frame 1, 
above).  Here's a dump of __in:

(gdb) print __in
$1 = (class std::basic_istream<char,std::char_traits<char> >
     &) @0xbfbfdc58: {<std::basic_ios<char,std::char_traits<char> >> = 
{<std::ios_base> = {_vptr.ios_base = 0xbb673360, static boolalpha = 
std::_S_boolalpha,
      static dec = std::_S_dec, static fixed = std::_S_fixed,
      static hex = std::_S_hex, static internal = std::_S_internal,
      static left = std::_S_left, static oct = std::_S_oct,
      static right = std::_S_right, static scientific = std::_S_scientific,
      static showbase = std::_S_showbase,
      static showpoint = std::_S_showpoint, static showpos = std::_S_showpos,
      static skipws = std::_S_skipws, static unitbuf = std::_S_unitbuf,
      static uppercase = std::_S_uppercase,
      static adjustfield = std::_S_adjustfield,
      static basefield = std::_S_basefield,
      static floatfield = std::_S_floatfield, static badbit = std::_S_badbit,
      static eofbit = std::_S_eofbit, static failbit = std::_S_failbit,
      static goodbit = std::_S_goodbit, static app = std::_S_app,
      static ate = std::_S_ate, static binary = std::_S_bin,
      static in = std::_S_in, static out = std::_S_out,
      static trunc = std::_S_trunc, static beg = std::_S_beg,
      static cur = std::_S_cur, static end = std::_S_end,
      _M_precision = 134694080, _M_width = 6, _M_flags = 0,
      _M_exception = 4098, _M_streambuf_state = std::_S_goodbit,
      _M_callbacks = 0x0, _M_word_zero = {_M_pword = 0x0, _M_iword = 0},
      _M_local_word = {{_M_pword = 0x0, _M_iword = 0}, {_M_pword = 0x0,
          _M_iword = 0}, {_M_pword = 0x0, _M_iword = 0}, {_M_pword = 0x0,
          _M_iword = 0}, {_M_pword = 0x0, _M_iword = 0}, {_M_pword = 0x0,
          _M_iword = 0}, {_M_pword = 0x0, _M_iword = 0}, {_M_pword = 0x0,
          _M_iword = 0}}, _M_word_size = 0, _M_word = 0x8, _M_ios_locale = {
        static none = 0, static ctype = 1, static numeric = 2,
        static collate = 4, static time = 8, static monetary = 16,
        static messages = 32, static all = 63, _M_impl = 0xbfbfde74,
        static _S_classic = 0xbb676620, static _S_global = 0xbb676620,
        static _S_categories = 0xbb671064, static _S_once = {pto_mutex = {
            ptm_magic = 858980355, ptm_errorcheck = 0, ptm_recursed = 0,
            ptm_waiters = 0x0, ptm_owner = 0x0}, pto_done = 1}}},
    _M_tie = 0xbb676620, _M_fill = 0 '\0', _M_fill_init = false,
    _M_streambuf = 0xbfbf0000, _M_ctype = 0xbfbfdc60, _M_num_put = 0xbb676760,
    _M_num_get = 0xbb6769a0}, _vptr.basic_istream = 0x80744ac, _M_gcount = 0}

Notice that the address 0xbb676620 is pointed to by _M_tie as well as several 
other members.  In fact, 0xbb676620 contains the global variable 
__gnu_internal::c_locale_impl.

(gdb) print __in._M_tie
$2 = (class std::basic_ostream<char,std::char_traits<char> > *) 0xbb676620
(gdb) x 0xbb676620
0xbb676620 <_ZN14__gnu_internal13c_locale_implE>:       0x00000012

(std::ostream::flush attempts to use the 0x12 as an address causing the 
violation)

I attemped to add a breakpoint at (all) the std::basic_istream constructors in 
libstdc++, but either I missed one or it is never called!?

Does this ring a bell with any one?  Suggestions?

Thanks,
Sverre

PS I see some weirdness with gdb.  stepi in most cases work like continue and 
some times gdb places itself in the background (an fg seems to restore it 
properly).