Debugging extensions under VS .NET 2003

[Gus Tabares]

This purpose of this post is to give a mini how-to on debugging Python
extensions written in C under Visual Studio .NET 2003. Please feel
free to correct any mistakes I may have made. Please realize that this
is not a comprehensive guide to debugging Python extensions; this is
only knowledge from what I have experienced. I hope that these
instructions will be handy to anyone who is having trouble debugging
Python extensions in a .NET 2003 environment.

If you want to be able to debug your extensions, you will to build a
debug version of the Python interpreter. The Python sources are freely
available on python.org.

You shouldn't need to build the entire Python environment, which
includes downloading openssl (and other) sources. Your main concern is
with the python project file.

After you compile the python project file, you should have the
following sets of files: python_d.exe (the debug interpreter),
python23_d.dll, python23_d.lib. You will need the .lib to link against
your debug extension.

Compile and link a debug version of your extension, making sure to
link against python23_d.lib. Also make sure that your extension is
named in the following format: pydname_d.pyd. The _d is necessary
when importing from the debug interpreter.

Set your breakpoints in your extension code from within .NET. Make
sure the debug command is the full path to debug version of the Python
interpreter.

It should bring up the debug interpreter when you start debugging.
From there you should be able to import your debug extension and
step-through your code from within .NET.

For more information and some examples, check out the readme file
located in the PC\example_nt directory of the Python sources. Note
that those instructions were written for Visual Studio 6 and not
specifically for .NET 2003.

Good luck,
Gus Tabares

 

[Michael Geary]

If you want to be able to debug your extensions, you will
[need] to build a debug version of the Python interpreter.

I'm very curious about this: Can anyone explain why it is necessary? (And is
it *really* necessary?)

It's a very unusual requirement. In ordinary Windows coding, one DLL is
independent from another. You can mix and match debug and nondebug DLLs with
no problem.

For example, suppose you are developing an Adobe Acrobat plug-in. You don't
have a debug version of Acrobat nor debug versions of the other plug-ins and
DLLs that Acrobat uses. But that doesn't matter. You can still build a debug
version of your own plug-in.

For that matter, consider any ordinary Windows application or DLL. You don't
have debug versions of the numerous standard Windows DLLs that will be
loaded alongside your code. But that has no effect on whether you can debug
your own code or not.

So what's going on with Python that it would require a debug version of
pythonxx.dll in order to debug your own extension DLL?

Obviously, if you want to trace through the pythonxx.dll code, you'd want a
debug version of that code. Is that the reason?

Other than that, the only possible reason would be if there are #if's in the
Python headers that compile different and incompatible data structures or
APIs depending on whether DEBUG is defined. If that is the problem, you
could easily work around it by building a *release* version of your DLL, and
in your project settings turn off optimization and turn on symbols.

-Mike

 

[Mike Rovner]

If you want to be able to debug your extensions, you will
[need] to build a debug version of the Python interpreter.

I'm very curious about this: Can anyone explain why it is necessary?
(And is it *really* necessary?)

That is completly unnecessary. If you want to debug python interpretor
itself
or suspect that your code isn't working as you want due to python behaivour
only than you may want to do that.

Mike