Possible bug in destructor code generation

Possible bug in destructor code generation

[Giancarlo Niccolai]

Hello,
After bumping my head a bit against a problem at the destruction of a huge
class, I started removing all the code, until I finally had a try at just
creating a new instance of said class and immediately destroying it.

As the problem didn't go away, I cut & pasted the class on the other file in
the same project that was using it, changed its name and instantiated that
instead. Everything went fine, the destructor worked like charm.

Now, finding the thing amusing, I checked the internals, and discovered that
the "official" version, on a separate source file, but going in the same
final library, doesn't access __i686.get_pc_thunk.bx, while the verbatim
copy I cut&pasted in the user file does.

In the specific, the class is a parser that has a long series of members,
each representing a parser token entity. Here follows the preamble of the
non working class destructor:


          Falcon::SourceParser::~SourceParser():
08061946:   push %ebp
08061947:   mov %esp,%ebp
08061949:   push %ebx
0806194a:   sub $0x14,%esp
0806194d:   mov 0x8(%ebp),%eax
08061950:   movl $0x8076328,(%eax)
08061956:   mov 0x8(%ebp),%eax
08061959:   add $0x2564,%eax
0806195e:   mov %eax,(%esp)
08061961:   call 0x805aa50 <_ZN6Falcon7Parsing11NonTerminalD1Ev@plt>
08061966:   mov 0x8(%ebp),%eax
08061969:   add $0x2528,%eax
0806196e:   mov %eax,(%esp)
08061971:   call 0x805aa50 <_ZN6Falcon7Parsing11NonTerminalD1Ev@plt>
08061976:   mov 0x8(%ebp),%eax
08061979:   add $0x24ec,%eax
0806197e:   mov %eax,(%esp)
08061981:   call 0x805aa50 <_ZN6Falcon7Parsing11NonTerminalD1Ev@plt>
08061986:   mov 0x8(%ebp),%eax
08061989:   add $0x24b0,%eax
0806198e:   mov %eax,(%esp)
08061991:   call 0x805aa50 <_ZN6Falcon7Parsing11NonTerminalD1Ev@plt>
08061996:   mov 0x8(%ebp),%eax
08061999:   add $0x2474,%eax
0806199e:   mov %eax,(%esp)
080619a1:   call 0x805aa50 <_ZN6Falcon7Parsing11NonTerminalD1Ev@plt>
080619a6:   mov 0x8(%ebp),%eax

.... etc, and here is the one of the working destructor:

          Falcon::MyParser::~MyParser():
00569222:   push %ebp
00569223:   mov %esp,%ebp
00569225:   push %esi
00569226:   push %ebx
00569227:   sub $0x10,%esp
0056922a:   call 0x3d88a7 <__i686.get_pc_thunk.bx>
0056922f:   add $0x2bcdc5,%ebx
00569235:   mov 0x8(%ebp),%eax
00569238:   mov -0x1650(%ebx),%edx
0056923e:   lea 0x8(%edx),%edx
00569241:   mov %edx,(%eax)
00569243:   mov 0x8(%ebp),%eax
00569246:   add $0x2244,%eax
0056924b:   mov %eax,(%esp)
0056924e:   call 0x3d5670 <_ZN6Falcon7Parsing11NonTerminalD1Ev@plt>
00569253:   mov 0x8(%ebp),%eax
00569256:   add $0x220c,%eax
0056925b:   mov %eax,(%esp)
0056925e:   call 0x3d5670 <_ZN6Falcon7Parsing11NonTerminalD1Ev@plt>
00569263:   mov 0x8(%ebp),%eax
00569266:   add $0x21d4,%eax
0056926b:   mov %eax,(%esp)
0056926e:   call 0x3d5670 <_ZN6Falcon7Parsing11NonTerminalD1Ev@plt>ax

... etc.

I have noticed that both the instances are created (in separate runs) at
0xB3F02948, and the last member (the first one getting destroyed) is located
at 0xB3F04B8C, exactly 0x2244 bytes below (see the first add $0x2244,%eax),
and in fact, I enter the NonTerminal destructor with this set as 0xB3F04B8C,
as expected.

The instance of SourceParser is located at the same address, and it's last
NonTerminal is still at 0xB3F04B8C, but the destructor receives this set as
0xB3F04EAC, exactly 0x2564 bytes below the instance location (see the first
add $0x2564,%eax), that is way outside the instance footprint in memory.

Anyone has any idea of what is causing this different behavior, and how I
could I fix it?

TIA,
Giancarlo Niccolai

=================================================================
This are the commands compiling the two files:

[  0%] Building CXX object
engine/CMakeFiles/falcon_engine.dir/sp/sourceparser.cpp.o
cd /home/gian/Progetti/FalconRepo/falcon/build_ne/engine && /usr/bin/c++  
-Dfalcon_engine_EXPORTS -DFALCON_ENGINE_EXPORTS -g -fPIC
-I/home/gian/Progetti/FalconRepo/falcon/include
-I/home/gian/Progetti/FalconRepo/falcon/build_ne/engine/../include
-I/home/gian/Progetti/FalconRepo/falcon/engine/re2    -Wall -Wextra -Werror
-Wno-error=uninitialized -lpthread -o
CMakeFiles/falcon_engine.dir/sp/sourceparser.cpp.o -c
/home/gian/Progetti/FalconRepo/falcon/engine/sp/sourceparser.cpp
/usr/bin/cmake -E cmake_progress_report
/home/gian/Progetti/FalconRepo/falcon/build_ne/CMakeFiles 
[  0%] Building CXX object engine/CMakeFiles/falcon_engine.dir/dyncompiler.cpp.o
cd /home/gian/Progetti/FalconRepo/falcon/build_ne/engine && /usr/bin/c++  
-Dfalcon_engine_EXPORTS -DFALCON_ENGINE_EXPORTS -g -fPIC
-I/home/gian/Progetti/FalconRepo/falcon/include
-I/home/gian/Progetti/FalconRepo/falcon/build_ne/engine/../include
-I/home/gian/Progetti/FalconRepo/falcon/engine/re2    -Wall -Wextra -Werror
-Wno-error=uninitialized -lpthread -o
CMakeFiles/falcon_engine.dir/dyncompiler.cpp.o -c
/home/gian/Progetti/FalconRepo/falcon/engine/dyncompiler.cpp


==========================================================
GCC version:

gian@hplin:~/Progetti/FalconRepo/falcon/build_ne$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=i686-linux-gnu
--host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)