From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7215 invoked by alias); 22 Jul 2004 19:26:30 -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 6960 invoked from network); 22 Jul 2004 19:26:28 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.77.109) by sourceware.org with SMTP; 22 Jul 2004 19:26:28 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i6MJQJPL000289; Thu, 22 Jul 2004 21:26:19 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i6MJQIAA001756; Thu, 22 Jul 2004 21:26:18 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id i6MJQIbG001753; Thu, 22 Jul 2004 21:26:18 +0200 (CEST) Date: Thu, 22 Jul 2004 20:51:00 -0000 Message-Id: <200407221926.i6MJQIbG001753@elgar.kettenis.dyndns.org> From: Mark Kettenis To: eliz@gnu.org CC: brobecker@gnat.com, mec.gnu@mindspring.com, cagney@gnu.org, gdb@sources.redhat.com In-reply-to: <2914-Thu22Jul2004221106+0300-eliz@gnu.org> Subject: Re: [6.2] PROBLEMS file References: <20040722093553.624FF4B104@berman.michael-chastain.com> <20040722151701.GA20596@gnat.com> <2914-Thu22Jul2004221106+0300-eliz@gnu.org> X-SW-Source: 2004-07/txt/msg00286.txt.bz2 Date: Thu, 22 Jul 2004 22:11:06 +0200 From: "Eli Zaretskii" > #0 0x7ffe0304 in ?? () > #1 0x77f7f4af in ntdll!ZwWaitForSingleObject () from ntdll.dll > #2 0x77e7788b in WaitForSingleObjectEx () from /WINDOWS/system32/KERNEL32.DLL > #3 0x00000778 in ?? () > #4 0x00000000 in ?? () from > #5 0x010df2c8 in ?? () > #6 0x000003e8 in ?? () > [snip] > Previous frame inner to this frame (corrupt stack?) > > In the backtrace above, only frame 0 to 2 are correct. After that, > GDB goes in limbo until it finally finds out that something is wrong. That is exactly what I saw with the DJGPP port. Was the program in your case compiled with DWARF2 debug info or with some other format? Look at the backtrace Eli. Frame #2 is executing Microsoft shit. I don't know what debugging format they use, and I don't think they ship their official releases with debugging info in it. The code looks like hand-optimized assembler. There is no hope our unwinder can make any sense out of it without some major work. The only thing that makes sense is somehow trust %ebp to point to some valid frame. There is no guarantee that it doesn't point to some garbage and if we trust it, we'll probably skip more a few frames in the backtrace. That's why it won't be the default. Mark