From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7387 invoked by alias); 13 Jun 2009 08:50:16 -0000 Received: (qmail 7284 invoked by uid 22791); 13 Jun 2009 08:50:16 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from ugmailsc.ugent.be (HELO ugmailsc.ugent.be) (157.193.49.118) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 13 Jun 2009 08:50:09 +0000 Received: from localhost (localhost [127.0.0.1]) by ugmailsc.ugent.be (Postfix) with ESMTP id 8342D1CF8D1 for ; Sat, 13 Jun 2009 10:50:06 +0200 (CEST) Received: from ugmailsc.ugent.be ([127.0.0.1]) by localhost (ugmailsc.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2QrBmrkgxgh for ; Sat, 13 Jun 2009 10:50:06 +0200 (CEST) Received: from cypress.ugent.be (cypress.ugent.be [157.193.71.48]) by ugmailsc.ugent.be (Postfix) with ESMTP id 5465F1CF8CB for ; Sat, 13 Jun 2009 10:50:06 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABcFM0qdwc4w/2dsb2JhbADPLIQNBQ Received: from mail.elis.ugent.be ([157.193.206.48]) by relayrec.ugent.be with ESMTP; 13 Jun 2009 10:50:06 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.elis.ugent.be (Postfix) with ESMTP id 07BD6918F24 for ; Sat, 13 Jun 2009 10:50:06 +0200 (CEST) Received: from mail.elis.ugent.be ([127.0.0.1]) by localhost (mail.elis.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWaobkfdSQG1 for ; Sat, 13 Jun 2009 10:50:03 +0200 (CEST) Received: from firefly.lan (unknown [91.182.182.47]) by mail.elis.ugent.be (Postfix) with ESMTP id D5E56918F23 for ; Sat, 13 Jun 2009 10:50:02 +0200 (CEST) Message-Id: From: Jonas Maebe 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 v926) Subject: Re: program does not crash when attached to gdbserver Date: Sat, 13 Jun 2009 08:50: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/msg00131.txt.bz2 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). 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 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. Jonas