This is the mail archive of the
mailing list for the GDB project.
Re: Crashing gdb with python-prettyprinting
- From: Tom Tromey <tromey at redhat dot com>
- To: Joachim Protze <joachim dot protze at wh2 dot tu-dresden dot de>
- Cc: gdb at sourceware dot org
- Date: Fri, 30 Jul 2010 13:12:11 -0600
- Subject: Re: Crashing gdb with python-prettyprinting
- References: <4C4EFC98.firstname.lastname@example.org>
>>>>> "Joachim" == Joachim Protze <email@example.com> 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
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
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