public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Joachim Protze <joachim.protze@wh2.tu-dresden.de>
To: gdb@sourceware.org
Subject: Crashing gdb with python-prettyprinting
Date: Tue, 27 Jul 2010 15:35:00 -0000	[thread overview]
Message-ID: <4C4EFC98.7080105@wh2.tu-dresden.de> (raw)

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}

             reply	other threads:[~2010-07-27 15:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-27 15:35 Joachim Protze [this message]
2010-07-30 19:12 ` Tom Tromey
2010-07-30 19:53   ` Petr Hluzín
2010-08-09 12:19   ` Joachim Protze
2010-08-10 10:57     ` Joachim Protze

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C4EFC98.7080105@wh2.tu-dresden.de \
    --to=joachim.protze@wh2.tu-dresden.de \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).