From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4166 invoked by alias); 12 Feb 2014 15:50:10 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 4137 invoked by uid 89); 12 Feb 2014 15:50:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: plane.gmane.org Received: from plane.gmane.org (HELO plane.gmane.org) (80.91.229.3) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 12 Feb 2014 15:50:08 +0000 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WDc4Y-0005Di-QZ for gcc-help@gcc.gnu.org; Wed, 12 Feb 2014 16:50:02 +0100 Received: from 93-36-14-158.ip57.fastwebnet.it ([93.36.14.158]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 12 Feb 2014 16:50:02 +0100 Received: from gc by 93-36-14-158.ip57.fastwebnet.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 12 Feb 2014 16:50:02 +0100 To: gcc-help@gcc.gnu.org From: Giancarlo Niccolai Subject: Possible bug in destructor code generation Date: Wed, 12 Feb 2014 15:50:00 -0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: Loom/3.14 (http://gmane.org/) X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00066.txt.bz2 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)