> > On Sun, Nov 22, 2009 at 2:51 PM, Carlos O'Donell > <car...@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.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
