From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19182 invoked by alias); 30 Jul 2010 19:12:21 -0000 Received: (qmail 19171 invoked by uid 22791); 30 Jul 2010 19:12:21 -0000 X-SWARE-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Jul 2010 19:12:16 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o6UJCE8N015634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Jul 2010 15:12:14 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o6UJCDOl020837; Fri, 30 Jul 2010 15:12:14 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o6UJCCII008698; Fri, 30 Jul 2010 15:12:12 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 16E4E3792BD; Fri, 30 Jul 2010 13:12:12 -0600 (MDT) From: Tom Tromey To: Joachim Protze Cc: gdb@sourceware.org Subject: Re: Crashing gdb with python-prettyprinting References: <4C4EFC98.7080105@wh2.tu-dresden.de> Date: Fri, 30 Jul 2010 19:12:00 -0000 In-Reply-To: <4C4EFC98.7080105@wh2.tu-dresden.de> (Joachim Protze's message of "Tue, 27 Jul 2010 17:34:48 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2010-07/txt/msg00127.txt.bz2 >>>>> "Joachim" == Joachim Protze writes: Joachim> i am writing on a python-prettyprinter for an quite complex Joachim> datastructure. It runs quite stable. But sometimes i get the appended Joachim> segfault. I can reproduce it by calling "info locals" and pressing Joachim> enter-key. I appended also the contents of the frame_info at the end of Joachim> the mail. For some reason at one point the frame_info gets corrupted. Joachim> Possibly overwritten by my python extension? It could be. A frame_info is a transient object, it will be overwritten whenever the frame cache is cleared. See reinit_frame_cache. If you want a more stable handle on a frame, you must use a frame_id. If there is code in the python layer that gets this wrong, please let us know about it, that would definitely be a bug. Joachim> Is it right, that the content of frame_info should not change Joachim> while the program is halted and i just call a series of "info Joachim> locals"? Aha. If a pretty-printer causes the frame cache to be invalidated, then the frame_info passed to print_frame_local_vars will be no good. That may be what you are seeing. You could verify this by putting a breakpoint on reinit_frame_cache and then doing "info locals". If it triggers, that is bad. Joachim> I'm new in debuging gdb by gdb. Can someone give me a hint, how Joachim> i can set a breakpoint in the outer gdb while the inner gdb is Joachim> running? What I do is use C-c to go back to the top gdb, then set my breakpoints, then "cont" to resume the inner gdb. Joachim> Or which way can i check the proper contents of frame_info Joachim> before the crash? Sometimes "frame" is useful, and there are various debug and verbose settings that can be handy. E.g., "set debug frame on". Joachim> I also tried to run gdb with duma to find the memory failure, Joachim> where the frame_info is overwritten, but with running duma each Joachim> step and each function call of gdb gets damn slow. I don't know what duma is. I tend to use valgrind for this sort of thing. That is slower than running native, but for most things, not unbearably so. Tom