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 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. I will go back immediately and review this. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
