Re: Crashing gdb with python-prettyprinting

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Joachim" == Joachim Protze <joachim.protze@wh2.tu-dresden.de> 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