Crashing gdb with python-prettyprinting

Crashing gdb with python-prettyprinting

[Joachim Protze]

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}

Re: Crashing gdb with python-prettyprinting

[Tom Tromey]

>>>>> "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

Re: Crashing gdb with python-prettyprinting

[Petr Hluzín]

On 30 July 2010 21:12, Tom Tromey <tromey@redhat.com> wrote:
> 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.

FYI: DUMA is a GLP library to detect buffer overruns and under-runs in
C and C++ programs. http://duma.sourceforge.net/

Basically it works the same way as ElectricFence (guard page after
each allocation).
I am sad to hear it is slow.

-- 
Petr Hluzin

Re: Crashing gdb with python-prettyprinting

[Joachim Protze]

Am 30.07.2010 21:12, schrieb Tom Tromey:
> 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.

I did this and found the point where it crashed - i did not remember,
that i use a parse_and_eval-call for each generation of an pp-object.
Now i was able to write a condensed version of my problem (see appendix)

In my own code, i have an object for each variable, that should be
printed. It caches the information, but i have to use a call to a
programm-function in each init. For more complex data structures this
also crashed on first call of "info locals".
To reproduce my failure just run the code below, set breakpoint to
return of main, load the python-script and "info local" till segfault

> 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.

Thanks for this hint - i did not recognize that the outer gdb will catch
the C-c signal, but thought i would interrupt the execution of the inner
program

Thanks and best regards

Joachim


----------------- pptest.c -----------------
enum test_enum{
  zero,
  one,
  two,
  three,
  four,
  five,
};

typedef int testint;

enum test_enum get_test_enum(int i){
  return (enum test_enum)i;
}

int main(int argc, char* argv[]){

  testint a, b, c, d, e, f;
  testint arr[]={0,1,2,3,4,5};

  a=0;
  b=1;
  c=2;
  d=3;
  e=4;
  f=5;

  return 0;
}

----------------- pptest.py -----------------
import gdb
import re

class pp_test:
    """testprinter with code interaction"""
    def __init__(self, id):
        self.id = id
    def to_string(self):
        return str(gdb.parse_and_eval("get_test_enum(%i)" % self.id))

def lookup_function (val):
    '''Look-up and return a pretty-printer that can print val.'''
    type = val.type;
    # If it points to a reference, get the reference.
    if type.code == gdb.TYPE_CODE_REF:
        type = type.target ()
    typename = str(type_from_value(type))
    for function in pp_dict:
        if function.search (typename):
            result = pp_dict[function] (val)
            return result
    return None

pp_dict = {}
pp_dict[re.compile('^testint$')] = lambda val: pp_test(val)
gdb.pretty_printers = []
gdb.pretty_printers.append (lookup_function)

Re: Crashing gdb with python-prettyprinting

[Joachim Protze]

I found a little mistake in my condensed version of the python part.
Appended the corrected versions.

-Joachim



----------------- pptest.c -----------------
enum test_enum{
  zero,
  one,
  two,
  three,
  four,
  five,
};

typedef int testint;

enum test_enum get_test_enum(int i){
  return (enum test_enum)i;
}

int main(int argc, char* argv[]){

  testint a, b, c, d, e, f;
  testint arr[]={0,1,2,3,4,5};

  a=0;
  b=1;
  c=2;
  d=3;
  e=4;
  f=5;

  return 0;
}

----------------- pptest.py -----------------
import gdb
import re

class pp_test:
    """testprinter with code interaction"""
    def __init__(self, id):
        self.id = id
    def to_string(self):
        return str(gdb.parse_and_eval("get_test_enum(%i)" % self.id))

def lookup_function (val):
    '''Look-up and return a pretty-printer that can print val.'''
    type = val.type;
    # If it points to a reference, get the reference.
    if type.code == gdb.TYPE_CODE_REF:
        type = type.target ()
    typename = str(type)
    for function in pp_dict:
        if function.search (typename):
            result = pp_dict[function] (val)
            return result
    return None

pp_dict = {}
pp_dict[re.compile('^testint$')] = lambda val: pp_test(val)
gdb.pretty_printers = []
gdb.pretty_printers.append (lookup_function)