From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3864 invoked by alias); 9 Sep 2014 15:48:54 -0000 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 Received: (qmail 3846 invoked by uid 89); 9 Sep 2014 15:48:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 09 Sep 2014 15:48:53 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s89FmoRq029290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 9 Sep 2014 11:48:50 -0400 Received: from localhost.localdomain (ovpn-112-44.ams2.redhat.com [10.36.112.44]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s89FmmoL007884; Tue, 9 Sep 2014 11:48:49 -0400 Message-ID: <540F2160.3010705@redhat.com> Date: Tue, 09 Sep 2014 15:48:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: Simeon S , gdb@sourceware.org Subject: Re: GDB Frame Filter - handling corrupt stack References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00030.txt.bz2 On 09/09/14 13:26, Simeon S wrote: It's a fairly simple filter, so I don't see much wrong with that. > > When the gdb "backtrace" command is issued, frames are decorated > followed by a gdb crash. This is what the last output from gdb is: > > UNIX ERR:tcsetattr:Input/output error > Segmentation fault (core dumped) I'd love to see a backtrace of this. It is not related to your issue, but it is a bug in the frame filters. It should print the error message below: > The stack seems to be corrupt which is what I suspect is causing the > crash. If the frame filter is disabled, the last line of the > "backtrace" command is: > > Backtrace stopped: previous frame inner to this frame (corrupt stack?) Yeah at this point the stack looks clobbered, or some kind of bug internal to GDB has occurred. > I haven't looked into why the stack is corrupt - all the frames of > interest to me are there. Is there a way to catch this condition to > avoid crashing? I am not interested in any of the corrupt frames - > what is in the stack is enough. No not really. Someone else may have an idea. > I guess I am looking for a mechanism to stop gdb iterating over > further frames if it detects a corrupt/invalid frame. The > documentation does say that gdb has to iterate over all stack frames > though. Even though the documentation does indeed say that, you can always slice/trim the iterator that is handed to the frame filter and return the sliced iterator. The trick is finding which frame would be the corrupted one and slicing appropriately. See the itertools Python module for iterator tools (including slicing). Cheers Phil