Mailing List Archive: Python: Dev

Pep 393 and debugging

Index | Next | Previous | View Threaded

kristjan at ccpgames

Apr 6, 2012, 6:27 AM

Post #1 of 4 (188 views)
Permalink

Pep 393 and debugging

I just had my first fun with Pep 393 strings and debuggers. Trying to debug a deadlocked python program, I'm trying to figure out the callstack of the thread in the debugger.

I ended up with something like:

(char*)&((PyASCIIObject*)(tstate->frame->f_code->co_filename))[1]

while previously, it was sufficient to do

(PyUnicodeObject*)(tstate->frame->f_code->co_filename)

Obviously this won't work for non-ASCII objects.

I wonder if there is a way to make this situation easier? Perhaps for "debug" builds, we can store some debug information in the frame object, e.g. utf8 encoding of the filename and function?

K

benjamin at python

Apr 6, 2012, 7:26 AM

Post #2 of 4 (167 views)
Permalink

Re: Pep 393 and debugging [In reply to]

2012/4/6 KristjÃ¡n Valur JÃ³nsson <kristjan [at] ccpgames>:
> I wonder if there is a way to make this situation easier?Â Perhaps for
> "debug" builds, we can store some debug information in the frame object,
> e.g. utf8 encoding of the filename and function?

Have you tried using the cpython gdb plugin? It should repr these
things for you.

--
Regards,
Benjamin
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

martin at v

Apr 7, 2012, 2:08 AM

Post #3 of 4 (159 views)
Permalink

Re: Pep 393 and debugging [In reply to]

> I wonder if there is a way to make this situation easier? Perhaps for
> "debug" builds, we can store some debug information in the frame object,
> e.g. utf8 encoding of the filename and function?

I'd like to stress Benjamin's recommendation. Dave Malcolm's gdb
extensions (requires gdb with Python support) are really powerful; they
will automatically render PyObject* by displaying the actual logical
value (and not just for strings).

Failing that, I use _PyObject_Dump to display strings; this requires a
debugger that can call functions in the debuggee (like gdb).

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

kristjan at ccpgames

Apr 7, 2012, 5:49 PM

Post #4 of 4 (160 views)
Permalink

Re: Pep 393 and debugging [In reply to]

Thanks, _PyObject_Dump sounds like just the ticket. Most of the time, the VS2010 debugger can just run functions willie nillie and thing should simply work.

________________________________________
Frá: "Martin v. Löwis" [martin [at] v]
Sent: 7. apríl 2012 09:08
To: Kristján Valur Jónsson
Cc: python-dev [at] python
Efni: Re: [Python-Dev] Pep 393 and debugging

> I wonder if there is a way to make this situation easier? Perhaps for
> "debug" builds, we can store some debug information in the frame object,
> e.g. utf8 encoding of the filename and function?

I'd like to stress Benjamin's recommendation. Dave Malcolm's gdb
extensions (requires gdb with Python support) are really powerful; they
will automatically render PyObject* by displaying the actual logical
value (and not just for strings).

Failing that, I use _PyObject_Dump to display strings; this requires a
debugger that can call functions in the debuggee (like gdb).

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads