Hi All,
Am a new subscriber to this list. Am facing an issue in deciphering core-files of applications with mixed C and libpython frames in it.
I was thinking of knowing any work that has been done with respect to getting into the actual python line (file-name.py:<line number>) from the libpython frames on the stack while debugging such core-files. If anybody knows some information on this, please let me know. I could not get any link on the web that talks about this feature.
Looking forward for your reply. Thanks and regards, Mithun
Bollywood, fun, friendship, sports and more... you name it, we have it at
http://in.groups.yahoo.com
Hi Mithun,
Because python-dev is a mailing list for the development of Python rather than development with Python, I believe you may not have posted to the best list. Further information about this distinction, and some discussion about potentially setting up a special-interest list exclusively for Python/C interactions, can be found in this recent thread:
http://mail.python.org/pipermail/python-dev/2007-June/073680.html
Regarding your question, I'll try to answer it as best I can: on our Windows application, we use Microsoft minidumps [1] instead of core dumps. At the time that a crash occurs and a minidump is written, we have some code that digs into the Python interpreter state to get a text traceback for every Python thread currently in execution at the time of the crash, which is appended to the log file that is sent with the minidump in the automated bug report. Doing this is a bit risky because it assumes that the relevant parts of the Python interpreter state aren't corrupt at the time of the crash, but precautions can be made to deal with this edge case. So while I can't help you get a bead on debugging core files, you may want to consider a similar solution on the Unix platform.
- Atul
[1] http://msdn2.microsoft.com/en-us/library/ms680369.aspx
On 6/28/07, Mithun R N mithun_rn@yahoo.co.in wrote:
Hi All,
Am a new subscriber to this list. Am facing an issue in deciphering core-files of applications with mixed C and libpython frames in it.
I was thinking of knowing any work that has been done with respect to getting into the actual python line (file-name.py:<line number>) from the libpython frames on the stack while debugging such core-files. If anybody knows some information on this, please let me know. I could not get any link on the web that talks about this feature.
Looking forward for your reply. Thanks and regards, Mithun
Bollywood, fun, friendship, sports and more... you name it, we have it at
http://in.groups.yahoo.com
Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/varmaa%40gmail.com
On Thu, Jun 28, 2007 at 09:41:06AM +0100, Mithun R N wrote:
Am a new subscriber to this list. Am facing an issue in deciphering core-files of applications with mixed C and libpython frames in it.
I was thinking of knowing any work that has been done with respect to getting into the actual python line (file-name.py:<line number>) from the libpython frames on the stack while debugging such core-files. If anybody knows some information on this, please let me know. I could not get any link on the web that talks about this feature.
Dave Beazley once worked on this subject:
http://www.usenix.org/events/usenix01/full_papers/beazley/beazley_html/index...
Dustin
>> Am a new subscriber to this list. Am facing an issue in deciphering
>> core-files of applications with mixed C and libpython frames in it.
>> I was thinking of knowing any work that has been done with respect to
>> getting into the actual python line (file-name.py:<line number>) from
>> the libpython frames on the stack while debugging such core-files. If
>> anybody knows some information on this, please let me know. I could
>> not get any link on the web that talks about this feature.
Sorry, I missed this the first time round and just saw Dustin's reply. The Python distribution comes with a gdbinit file in the Misc directory. I use it frequently to display Python stack traces from within GDB. Here's the most recent copy online:
http://svn.python.org/view/python/trunk/Misc/gdbinit?view=markup
The following commands are implemented:
pystack - display the full stack trace
pystackv - as above, but also display local variables
pyframe - display just the current frame
pyframev - as above, but also display local variables
up, down - move up or down one C stack frame, but display Python
frame if you move into PyEval_EvalFrame
This should all work within active sessions and sessions debugging core files (e.g., no active process).
It needs some rework. For instance, it assumes you're running within Emacs and puts out lines gud can use to display source lines. These look a little funky when debugging from a terminal window.
Skip
Hi All,
Thanks much for your suggestions and help. Shall get back after reading through and trying some stuff mentioned in the emails.
Thanks and regards, Mithun
--- skip@pobox.com wrote:
>> Am a new subscriber to this list.
Am facing
an issue in deciphering
>> core-files of applications with mixed C and
libpython frames in it.
>> I was thinking of knowing any work that has
been done with respect to
>> getting into the actual python line
(file-name.py:<line number>) from
>> the libpython frames on the stack while
debugging such core-files. If
>> anybody knows some information on this,
please let me know. I could
>> not get any link on the web that talks about
this feature.
Sorry, I missed this the first time round and just saw Dustin's reply. The Python distribution comes with a gdbinit file in the Misc directory. I use it frequently to display Python stack traces from within GDB. Here's the most recent copy online:
http://svn.python.org/view/python/trunk/Misc/gdbinit?view=markup
The following commands are implemented:
pystack - display the full stack trace
pystackv - as above, but also display local
variables pyframe - display just the current frame pyframev - as above, but also display local variables up, down - move up or down one C stack frame, but display Python frame if you move into PyEval_EvalFrame
This should all work within active sessions and sessions debugging core files (e.g., no active process).
It needs some rework. For instance, it assumes you're running within Emacs and puts out lines gud can use to display source lines. These look a little funky when debugging from a terminal window.
Skip
Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download Now! http://messenger.yahoo.com/download.php
-
Atul Varma -
Dustin J. Mitchell -
Mithun R N -
skip＠pobox.com