From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20201 invoked by alias); 10 Jan 2007 15:29:08 -0000 Received: (qmail 20191 invoked by uid 22791); 10 Jan 2007 15:29:07 -0000 X-Spam-Check-By: sourceware.org Received: from vir-del-04.spheriq.net (HELO vir-del-04.spheriq.net) (194.50.41.43) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 10 Jan 2007 15:28:58 +0000 Received: from vir-out-01.spheriq.net ([194.50.41.30]) by vir-del-04.spheriq.net with ESMTP id l0AFSunR005060 for ; Wed, 10 Jan 2007 15:28:56 GMT Received: from vir-cus-01.spheriq.net (vir-cus-01.spheriq.net [194.50.41.85]) by vir-out-01.spheriq.net with ESMTP id l0AFStr3025374 for ; Wed, 10 Jan 2007 15:28:56 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by vir-cus-01.spheriq.net with ESMTP id l0AFSrte015661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Jan 2007 15:28:54 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 00C01DA43; Wed, 10 Jan 2007 15:28:52 +0000 (GMT) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 89F4147490; Wed, 10 Jan 2007 15:28:52 +0000 (GMT) Received: from [164.129.15.13] (bri1043.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.7.5a-GA) with ESMTP id CIJ20834 (AUTH stubbsa); Wed, 10 Jan 2007 15:28:50 GMT Message-ID: <45A50632.8000605@st.com> Date: Wed, 10 Jan 2007 15:29:00 -0000 From: Andrew STUBBS User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Christoph Bartoschek Cc: gdb@sourceware.org Subject: Re: Differences between program runs with and without gdb References: <200701101517.20024.bartoschek@or.uni-bonn.de> <200701101548.40353.bartoschek@or.uni-bonn.de> <45A4FED2.30803@st.com> <200701101558.33752.bartoschek@or.uni-bonn.de> In-Reply-To: <200701101558.33752.bartoschek@or.uni-bonn.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2007-01/txt/msg00174.txt.bz2 Christoph Bartoschek wrote: > There is no stepping and no breakpoints are active. The program starts, it > terminates and the debugger is quitted. In that case GDB is still quietly and automatically monitoring threads and signals, of which you say there are none, and also the dynamic linker. I don't know what system you are on or what your program does but it may be that there is an invisible breakpoint every time a library is loaded (GDB uses them to load the symbols from the library). I don't know how that could be affecting anything though. It's possible that a breakpoint has been set on some data somehow - if you have a symbol with just the wrong name. Perhaps you pass in slightly different parameters or environment when you use GDB. I expect you checked this already. There's always cache effects of course. Perhaps your program does something unsafe (self modifying code?) and GDB's influence is just enough to perturb the results. Instead of GDB, have you tried running it "under" something else. ptrace or valgrind perhaps, assuming your on a compatible system. Well there's some ideas anyway. Andrew