Bug#554574: libstdc++6: apt segfaults on hppa
>
> On Sun, Nov 22, 2009 at 2:51 PM, Carlos O'Donell
> <carlos@systemhalted.org> wrote:
> > This happens because the original locale object was created at address
> > 0xbff01c20. However, when apt-get calls "std::basic_ios<char,
> > std::char_traits<char> >::init" it passes in the address 0xbff01c18.
> > So we went from a constructor using this as 0xbff01c20, to eventually
> > passing this as 0xbff01c18 to a template. The pointer to the
> > std::ios_base object is now off by 8 bytes and this causes the crash.
> >
> > What happened here? Why does ReadConfigFile() think that the object is
> > in a different location?
> >
> > Any hints on how to track this down?
The ptype command might help to display the object and to see what's
changed.
> The problem is here, we read 0xa8 here from libstdc++6:
>
> (gdb) x/16x $ret0 - 0xc
> 0x40437778 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si>:
> 0x000000a8 0x00000000 0x40437b30 0x401b2b96
> 0x40437788 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+16>:
> 0x401b2b9e 0xffffff58 0xffffff58 0x40437b30
> 0x40437798 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+32>:
> 0x401b2ba6 0x401b2bae 0x00000000 0x40437834
>
> Then we add this offset to the base location of the object on the
> stack and we compute 0xbff01c18, instead of computing 0xbff01c20 as we
> would expect.
>
> It looks like the layout of the object in libstdc++.so.6 has changed,
> my guess is that the changes I made to the locking types in glibc have
> caused the layout to be perturbed.
>
> While I set out the glibc types exactly as before (binary compatible),
> the alignment restrictions were changed subtly.
Excellent debugging!
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Reply to: