From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25620 invoked by alias); 13 Jun 2009 13:54:10 -0000 Received: (qmail 25609 invoked by uid 22791); 13 Jun 2009 13:54:09 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 13 Jun 2009 13:54:02 +0000 X-RZG-AUTH: :O2kGeEG7b/pS1E6gSHOyjPKyNsg/5l1He+DzFS97kzBIQZrlxnMyS+hF1TEzmA== X-RZG-CLASS-ID: mo00 Received: from [192.168.222.5] (187-3-7-175-sa.cpe.vivax.com.br [187.3.7.175]) by post.strato.de (mrclete mo1) (RZmta 18.39) with AES128-SHA encrypted ESMTP id e02bc7l5DBvOQ8 for ; Sat, 13 Jun 2009 15:53:58 +0200 (MEST) Message-Id: From: "Dr. Rolf Jansen" To: gdb@sourceware.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: program does not crash when attached to gdbserver Date: Sat, 13 Jun 2009 13:54:00 -0000 References: X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00134.txt.bz2 Jonas, many thanks for your reply! Am 13.06.2009 um 05:50 schrieb Jonas Maebe: > On 13 Jun 2009, at 00:55, Dr. Rolf Jansen wrote: > >> The problem is that the application crashes consistently after a >> certain sequence of user interactions if it runs by its own. >> However, the same binary does not crash, once it is attached to >> gdbserver, and it does not crash even when continuing with a >> couple of stress tests beyound the point at which it would have >> crashed without gdbserver. >> >> It would help so much to find the bug if the program would crash >> into gdb and if gdb could show me the related source code. This >> usually works quite well, for example when writing to memory at NULL. >> >> Perhaps somebody has an idea about what type of bug might cause the >> behaviour described above. > > As you surmise below: probably using uninitialised and/or freed > memory. > >> There was a debugger for Mac OS Classic called MacsBug, that had a >> setting for scrambling the memory, so that accessing released >> memory would immediately result into a crash. I cannot seem to find >> a similar feature in gdb. Does gdb have any settings, that I can try? > > In general, this is a feature of the compiler and/or run time, > rather than of the debugger (the debugger cannot know how the memory > manager of your run time works, so unless you exclusively use OS or > OS-supplied library functions, it cannot scramble anything). I can understand this, and as a matter of fact I would have expected that the debugger does not interact with the memory management, my problem is that it acts somehow on mm and the runtime. It would already be of help for me if somebody could point me to some possible areas of interaction, which could make up for the above mentioned different behaviour of running the same binary with and without gdbserver being attached. > E.g., in case of the Free Pascal Compiler, there are the -gttt > (scramble all local variables on function entry) and -gh (use the > heaptrc unit, which, a.o., scrambles all freed memory) options. > > For GCC, you can have a look which of these work on your target > platform: http://en.wikipedia.org/wiki/Memory_debugger I experimented a bit with memwatch, to no more avail than finding some freeing-NULL occasions. I would not have bothered you with my case, if I would still have own ideas to try. Anyway, I will have a look to the other options mentioned at the wiki page. > Regarding scrambling local variables on function entry, I believe > that recent GCC's support doing that as well, but I don't know the > command line option by heart. For several reasons (which would make up for a story of its own), it would surprise me, if this is problem with local variables, but I will have a look in that, anyway. From memwatch I know that there are more than 70000 memory allocations from which half of it are already free'd until the crash occurs. My program is written in objective-c and my part consist of 30000 lines of code and the frameworks that are in use are about 150000 lines, which makes this problem not a trivial one. My part and the frameworks are compiled with complete debugging symbols, and I can step through every single part of the whole program. So, for me it would already be perfect if gdb/gdbserver could simply stop the program where without gdbserver being attached it would crash. Rolf Jansen