From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31693 invoked by alias); 23 Dec 2009 21:28:07 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 31681 invoked by uid 22791); 23 Dec 2009 21:28:06 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Subject: Re: Pretty-printing backtraces when "python" is the inferior process From: David Malcolm To: Tom Tromey Cc: archer@sourceware.org In-Reply-To: References: <1261524321.2228.70.camel@brick> Content-Type: text/plain; charset="UTF-8" Date: Wed, 23 Dec 2009 21:28:00 -0000 Message-Id: <1261603718.2345.39.camel@brick> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2009-q4/txt/msg00133.txt.bz2 On Wed, 2009-12-23 at 12:32 -0700, Tom Tromey wrote: > >>>>> "David" == David Malcolm writes: > > David> I'm experimenting with archer, and adding python hooks for when the > David> inferior process is itself Python. > > Awesome. > > David> I've attempted to do this, but am running into an issue. (this is on > David> Fedora 12 i386) > > David> $ git checkout --track -b archer-tromey-python origin/archer-tromey-python > > David> (gdb) frame 9 > David> #9 PyEval_EvalFrameEx (f=, throwflag= David> optimized out>) at Python/ceval.c:2389 > David> 2389 x = call_function(&sp, oparg); > > I tried this same example on my F11 box. > > I am not sure exactly what bug you are hitting, but I think it is > something that is fixed either in CVS head or in some other Fedora > patch. I say that because the example fails with archer-tromey-python, > but works with the F11 system gdb. I think it has to do with the > representation of inlined frames -- when I trace into lookup_symbol, if > I look at the blocks I eventually see: > > (gdb) p *block.superblock.function > $5 = { > ginfo = { > name = 0x92be5e8 "call_function", > > I don't fully understand this, because I would have expected the > selected frame to be PyEval_EvalFrameEx, not call_function. However, > I'm planning to do a merge from trunk in early January, which may fix > the problem. In the meantime, maybe using archer-jankratochvil-fedora12 > would be better. Or even using the system gdb... though that will make > it a bit harder if you need to modify the python libraries. Thanks for looking at this. Unfortunately it seems to be failing with both the system Fedora 12 gdb and with archer-jankratochvil-fedora12: FWIW the function in question (PyEval_EvalFrameEx) is defined in http://svn.python.org/view/python/trunk/Python/ceval.c?view=markup and the local I'm most interested in is: PyCodeObject *co; this variable contains the interesting information on what's going on at the python level in a python vm stack frame. For example: (gdb) p (char*)((PyStringObject*)co->co_filename)->ob_sval $3 = 0x810c764 "/usr/lib/python2.6/site-packages/istanbul/main/main.py" (gdb) p (char*)((PyStringObject*)co->co_name)->ob_sval $4 = 0xb7fd9374 "main" (gdb) p co->co_firstlineno $5 = 87 (gdb) p *co $6 = {ob_refcnt = 2, ob_type = 0x5039ae0, co_argcount = 1, co_nlocals = 4, co_stacksize = 3, co_flags = 67, co_code = 0xb7fb49e0, co_consts = 0x811f0d4, co_names = 0x810c48c, co_varnames = 0x81261bc, co_freevars = 0xb7fa402c, co_cellvars = 0xb7fa402c, co_filename = 0x810c750, co_name = 0xb7fd9360, co_firstlineno = 87, co_lnotab = 0x811f5d0, co_zombieframe = 0x0} etc and this could be used to pretty-print the python-level info. The errors I'm seeing are as before: Fedora 12 system gdb: $ /usr/bin/gdb --args /usr/bin/python /usr/bin/istanbul GNU gdb (GDB) Fedora (7.0-7.fc12) [snip] (gdb) frame 9 #9 PyEval_EvalFrameEx (oparg=, pp_stack=) at Python/ceval.c:2389 2389 x = call_function(&sp, oparg); (gdb) python print gdb.parse_and_eval("co") 0x81274e8 (gdb) python print gdb.selected_frame().read_var('co') Traceback (most recent call last): File "", line 1, in ValueError: variable 'co' not found Error while executing Python code. With archer-jankratochvil-fedora12 it fails in the same way: $ ./gdb/gdb --args /usr/bin/python /usr/bin/istanbul GNU gdb (GDB) 7.0 [snip] (gdb) python print gdb.parse_and_eval("co") 0x81274e8 (gdb) python print gdb.selected_frame().read_var('co') Traceback (most recent call last): File "", line 1, in ValueError: variable 'co' not found Error while executing Python code. (this was only a shallow inspection; got to run to catch a plane. This could be error on my part of course; I know very little about the innards of gdb). Dave