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}
next 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).