From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9186 invoked by alias); 27 Jul 2010 15:35:02 -0000 Received: (qmail 9131 invoked by uid 22791); 27 Jul 2010 15:35:01 -0000 X-SWARE-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50,T_LOTS_OF_MONEY,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from atlantis.wh2.tu-dresden.de (HELO atlantis.wh2.tu-dresden.de) (141.30.228.39) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Jul 2010 15:34:52 +0000 Received: from [141.30.223.201] (x0862b.wh5.tu-dresden.de [141.30.223.201]) by atlantis.wh2.tu-dresden.de (Postfix) with ESMTPSA id B87E066E18 for ; Tue, 27 Jul 2010 17:34:43 +0200 (CEST) Message-ID: <4C4EFC98.7080105@wh2.tu-dresden.de> Date: Tue, 27 Jul 2010 15:35:00 -0000 From: Joachim Protze User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100515 Icedove/3.0.4 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Crashing gdb with python-prettyprinting Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit 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/msg00100.txt.bz2 Hi, i am writing on a python-prettyprinter for an quite complex datastructure. It runs quite stable. But sometimes i get the appended segfault. I can reproduce it by calling "info locals" and pressing enter-key. I appended also the contents of the frame_info at the end of the mail. For some reason at one point the frame_info gets corrupted. Possibly overwritten by my python extension? Is it right, that the content of frame_info should not change while the program is halted and i just call a series of "info locals"? I'm new in debuging gdb by gdb. Can someone give me a hint, how i can set a breakpoint in the outer gdb while the inner gdb is running? Or which way can i check the proper contents of frame_info before the crash? I also tried to run gdb with duma to find the memory failure, where the frame_info is overwritten, but with running duma each step and each function call of gdb gets damn slow. I dont know, if it is important, but the arch i'm working on is ia64. I tried gdb-7.1 and yesterdays snapshot: gdb-7.2.50.20100726 Gratefully waiting for your advices, Joachim ------------- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 2305843009219149824 (LWP 29330)] 0x40000000000b8a90 in frame_unwind_arch (next_frame=0x21c) at frame.c:2061 2061 if (!next_frame->prev_arch.p) (gdb) bt #0 0x40000000000b8a90 in frame_unwind_arch (next_frame=0x21c) at frame.c:2061 #1 0x40000000000b8a20 in get_frame_arch (this_frame=0x6000000000635220) at frame.c:2055 #2 0x400000000057c180 in dwarf_expr_read_reg (baton=0x607fffffff16dc28, dwarf_regnum=12) at dwarf2loc.c:140 [....] (gdb) p *(struct frame_info *)0x6000000000635220 $1 = {level = 1612, pspace = 0x1, aspace = 0x603fffffffffe060, prologue_cache = 0x0, unwind = 0x10, prev_arch = {p = 1, arch = 0x14}, prev_pc = {p = 1, value = 24}, prev_func = {addr = 1, p = 28}, this_id = {p = 1, value = {stack_addr = 528, code_addr = 1, special_addr = 532, stack_addr_p = 1, code_addr_p = 0, special_addr_p = 0, inline_depth = 0}}, base = 0x218, base_cache = 0x1, next = 0x21c, prev_p = 1, prev = 0x690, stop_reason = UNWIND_NULL_ID}