From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14083 invoked by alias); 25 Apr 2005 08:00:04 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 13916 invoked from network); 25 Apr 2005 07:59:57 -0000 Received: from unknown (HELO andromeda.onevision.de) (212.77.172.62) by sourceware.org with SMTP; 25 Apr 2005 07:59:57 -0000 Received: from [192.168.5.120] (oppenheim.onevision.de [192.168.5.120]) by andromeda.onevision.de (8.13.1/8.12.9/ROSCH/DDB) with ESMTP id j3P7xux9021911; Mon, 25 Apr 2005 09:59:56 +0200 Message-ID: <426CA356.60901@onevision.de> Date: Mon, 25 Apr 2005 08:00:00 -0000 From: Roland Schwingel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 MIME-Version: 1.0 To: Mark Kettenis CC: gdb@sourceware.org, gdb@sources.redhat.com Subject: Re: gdb stack trace problems (Addendum) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-04/txt/msg00171.txt.bz2 Message-ID: <20050425080000.Gg6asTNCXcxg7vfOY4C4rAXnfNRbowip5Cfk-7qOTPA@z> Hi... Mark Kettenis wrote on 22.04.2005 19:51:14: > Hi Mark... > > Have you already had some time to look into it? > > I did, but I didn't have find the time to reply yet ;-). Thank you very much... > Anyway, there is a serious problem here. The code you show is > basically undebuggable. > [...] > The only thing we can do here is trust the frame pointer, like we used > to do in the old days. The problem with that is that it's very likely > to (silently) skip some function calls. In your particular example it > probably would appear as if your code called SleepEx directly and > there would be no trace of Sleep at all. That can be quite puzzling. > > I'm thinking about adding an option to instruct gdb to "trust" the > frame pointer. I'm not going to make it the default though. I really > prefer seeing an abviously wrong backtrace over gdb silently skipping > function calls in its backtraces. Well the present situation is quite problematic for us. In past days (gdb 5.3) when an application crashed we had a quite accurate backtrace. It wasn't wrong (for us). Finding/Fixing bugs was very easy. GDB has been very useful here. With gdb 6.x we are no longer able to get a backtrace in these cases (in about 95% of all cases). This is a serious problem and makes gdb 6.x quite unusable for us (and maybe others on windows). Having at least an option for enabling that feature would be IMHO absolutely necessary. I wonder why other users on windows haven't complained earlier about this problem. So will you implement such an option? I am quite unfamiliar with the internals of gdb's stack unwinding, so I am not of much help here. But whenever I can do something to help to fix this I am happily volunteering to do so. Thanks again for your help Mark! Roland