From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6458 invoked by alias); 9 Dec 2012 13:19:04 -0000 Received: (qmail 6449 invoked by uid 22791); 9 Dec 2012 13:19:02 -0000 X-SWARE-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SARE_BAYES_5x8,TW_SM,TW_SV X-Spam-Check-By: sourceware.org Received: from mail-da0-f41.google.com (HELO mail-da0-f41.google.com) (209.85.210.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 09 Dec 2012 13:18:56 +0000 Received: by mail-da0-f41.google.com with SMTP id e20so831331dak.0 for ; Sun, 09 Dec 2012 05:18:56 -0800 (PST) Received: by 10.66.85.39 with SMTP id e7mr19259207paz.63.1355059136239; Sun, 09 Dec 2012 05:18:56 -0800 (PST) Received: from [127.0.0.1] ([115.196.200.48]) by mx.google.com with ESMTPS id d9sm10062930paw.33.2012.12.09.05.18.45 (version=SSLv3 cipher=OTHER); Sun, 09 Dec 2012 05:18:55 -0800 (PST) Message-ID: <50C49050.2020700@gmail.com> Date: Sun, 09 Dec 2012 13:19:00 -0000 From: asmwarrior User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0a1 MIME-Version: 1.0 To: Pierre Muller CC: gdb-patches@sourceware.org Subject: Re: [RFC-v5] Fix .text section offset for windows DLL (was Calling __stdcall functions in the inferior) References: <20121024194517.GK3555@adacore.com> <011901cdb2ab$48076b90$d81642b0$@muller@ics-cnrs.unistra.fr> <20121105171121.GA2972@adacore.com> <50991f5f.8382440a.1100.ffff82abSMTPIN_ADDED@mx.google.com> <509ABA17.30507@redhat.com> <000301cdbd96$f5cd9f10$e168dd30$@muller@ics-cnrs.unistra.fr> <20121122173019.GF9964@adacore.com> <15690.5992342674$1353883881@news.gmane.org> <87624si9ur.fsf@fleche.redhat.com> <001501cdccaf$ad85e9b0$0891bd10$@muller@ics-cnrs.unistra.fr> <20121207071035.GG31477@adacore.com> <50C20A66.70002@gmail.com> <29545.4593528577$1354894901@news.gmane.org> <50C21696.7040006@gmail.com> <50c218e5.2850b40a.0281.ffffbef4SMTPIN_ADDED_BROKEN@mx.google.com> <50C34C75.3050803@gmail.com> <50c38058.03d0d80a.31dd.4e28SMTPIN_ADDED_BROKEN@mx.google.com> <50C3FBE2.4030702@gmail.com> <50c487f8.a813b40a.57d7.ffffdc7fSMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: <50c487f8.a813b40a.57d7.ffffdc7fSMTPIN_ADDED_BROKEN@mx.google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-12/txt/msg00221.txt.bz2 On 2012-12-9 20:45, Pierre Muller wrote: > Hi Yuanhui, > > >> -----Message d'origine----- >> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches- >> owner@sourceware.org] De la part de asmwarrior >> Envoyé : dimanche 9 décembre 2012 03:48 >> À : Pierre Muller >> Cc : 'Joel Brobecker'; 'Eli Zaretskii'; gdb-patches@sourceware.org >> Objet : Re: [RFC-v5] Fix .text section offset for windows DLL (was Calling >> __stdcall functions in the inferior) >> >> On 2012-12-9 2:00, Pierre Muller wrote: >>> This memory corruption is rather odd... >>> it seems that the rva_end of index=2 seems to contains the same data >>> as the section_name for index 4... >>> This array is really created only inside read_pe_exported_syms >>> so that it would be worth trying to add a breakpoint at that function, >>> and step over it for ntdll.dll to understand when the data gets >> corrupted... >>> Would it be possible for you to upload the codeblocks executable that >> triggers >>> the problem somewhere so I could >>> check if I get the same errors and debug further? >>> >>> I have no idea what is going on... >>> >>> >>> Pierre Muller >>> >> Hi, Pierre: >> >> I think you can test the official Codeblocks release 12.11. >> >> 1, you can download the release from: http://www.codeblocks.org/downloads/26 >> select this one: codeblocks-12.11-setup.exe >> Note: the binaries in this release contain debug information (build with -g >> options) > > Strange because I did install program that you are refereeing to above, > but the installed codeblock.exe files doesn't contain any debug information, > see elow: > > C:\Program Files (x86)\CodeBlocks\debug>dir codeblocks.exe > Le volume dans le lecteur C s'appelle OS > Le numéro de série du volume est 4801-E7AF > > Répertoire de C:\Program Files (x86)\CodeBlocks\debug > > 28/11/2012 20:08 1 253 390 codeblocks.exe > 1 fichier(s) 1 253 390 octets > 0 Rép(s) 2 344 669 184 octets libres > > C:\Program Files (x86)\CodeBlocks\debug>gdbcvs codeblocks.exe > GNU gdb (GDB) 7.5.50.20121106-cvs > Copyright (C) 2012 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i686-pc-mingw32". > For bug reporting instructions, please see: > ... > Reading symbols from C:\Program Files (x86)\CodeBlocks\debug\codeblocks.exe...(no debugging symbols found)...done. > (gdb) q > > C:\Program Files (x86)\CodeBlocks\debug>objdump -h codeblocks.exe > > codeblocks.exe: file format pei-i386 > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text 000b550c 00401000 00401000 00000400 2**4 > CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA > 1 .data 00000100 004b7000 004b7000 000b5a00 2**2 > CONTENTS, ALLOC, LOAD, DATA > 2 .rdata 0001bb30 004b8000 004b8000 000b5c00 2**5 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 3 .eh_frame 00000438 004d4000 004d4000 000d1800 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 4 .bss 000086dc 004d5000 004d5000 00000000 2**5 > ALLOC > 5 .edata 00000985 004de000 004de000 000d1e00 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 6 .idata 00014120 004df000 004df000 000d2800 2**2 > CONTENTS, ALLOC, LOAD, DATA > 7 .CRT 00000018 004f4000 004f4000 000e6a00 2**2 > CONTENTS, ALLOC, LOAD, DATA > 8 .tls 00000020 004f5000 004f5000 000e6c00 2**2 > CONTENTS, ALLOC, LOAD, DATA > 9 .rsrc 0003bc0c 004f6000 004f6000 000e6e00 2**2 > CONTENTS, ALLOC, LOAD, DATA > 10 .reloc 0000f2c8 00532000 00532000 00122c00 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > > C:\Program Files (x86)\CodeBlocks\debug> > > Are you sure it's the file from codeblocks-12.11-setup.exe > that you are analyzing? Sorry, I may be wrong, but look at this post in C::B forum: http://forums.codeblocks.org/index.php/topic,17200.msg117936.html#msg117936 One of the C::B developer said that the debug information is not stripped in the exe/dll files. But whether the codeblocks.exe contains the debug information or not, it did crash gdb when I run the command: file: file d:/software/cb/codeblocks/codeblocks.exe > STOP right here! > > You get a warning about memory corruption before the crash! > So you need to find out why you get this. Here, in my system, I have two codeblocks.exe, one is under my svn_trunk folder(build myself), which cause my gdb crash when I enter "r" command. The other one is from the "codeblocks-12.11-setup.exe", which cause gdb crash when I run the "file xxxxx" command. I'm not sure they refer to the same issue. > The best would be to start GDB from gdb_stable using > start command and place an access watchpoint on the location > that is given (if the address is the same for different runs...) > awatch *0x2de4228 > should allow to get more information. > It might not work right after start command, > because the corresponding memory block might > not yet be accessible by the program, > in that case try to add a breakpoint > at read_pe_exported_syms function, > and try to insert the watchpoint at each stop at that breakpoint. > > This way, we might finally understand which allocated memory > is accessed after being freed. It looks like I need to learn some gdb commands I have never used. Do I need to upload myself build codeblocks binaries somewhere that you want try it? Or you can already build codeblocks yourself? Yuanhui Zhang