3

I downloaded and installed the Python 2.7.6 64-bit Windows distribution (python-2.7.6.amd64.msi) and also downloaded the source code (Python-2.7.6.tgz) and PDB symbols (python-2.7.6.amd64-pdb.zip), all from http://python.org/ftp/python/2.7.6/, and specified the location of the PDBs as explained here:

enter image description here

However, when debugging Python code in Python Tools for Visual Studio 2013, I get errors that suggest the symbols do not correspond to the source code:

enter image description here

^ What? This user does not exist on my machine!

enter image description here

Also, even when I find the corresponding file, the debugger jumps around as I step through the code - sometimes it follows the lines of code which are there, sometimes it skips to the wrong line. This is typical when the symbols do not correspond to the source code.

How can I fix this? Why do the distribution, source code and symbols on Python's own website not seem to correspond to each other?

1''
  • 26,823
  • 32
  • 143
  • 200
  • Can you tell a little bit more about how you started debugging? Did you have a VS project that you ran with debug from VS, or did you use Debug -> Attach to Process, and if the latter, which code types did you choose? Judging from the screenshots, you actually ended up debugging python.exe as a C program - is that what you're actually trying to do? (in contrast, PTVS mixed-mode debugging is something different) – Pavel Minaev May 02 '14 at 23:47
  • (BTW, the "original location" is the absolute path of the .c file from which the binary was built on the machine on which it was built - in this case, it was the machine of Martin von Löwis, the maintainer of Python on Windows. It doesn't mean that you have to have the file at the same location - so long as the filename and the contents match, you're good to go.) – Pavel Minaev May 02 '14 at 23:48
  • @PavelMinaev I'm using PTVS mixed-mode debugging with a `.pyproj`. Thanks for the explanation about the "original location". However, why does the second error - "The source file is different from when the module was built" - occur? – 1'' May 02 '14 at 23:55
  • Actually, that error is probably spurious. The skipping around might be because I am using a release build of Python (from the installer). What do you think? – 1'' May 03 '14 at 00:02
  • I suspect that files get changed as part of the build process - e.g. a build number is written somewhere? When I previously did the same, I was also getting source mismatch complaints from the compiler, but no issues whatsoever if the warning is just turned off - the code actually does match. – Pavel Minaev May 05 '14 at 18:33
  • Jumping around in C code would be expected in an optimized build, yes. I wasn't sure from your description whether you're seeing this in C code or in Python code, however. It should not happen in Python code regardless of whether the interpreter is built debug or release. – Pavel Minaev May 05 '14 at 18:34
  • @PavelMinaev Yes, this was in C code. Feel free to put your comments into an answer and I'll accept it. Thanks! – 1'' May 06 '14 at 00:51

1 Answers1

4

The "original location" is the absolute path of the .c file from which the binary was built on the machine on which it was built - in this case, it was the machine of Martin von Löwis, the maintainer of Python on Windows. It doesn't mean that you have to have the file at the same location - so long as the filename and the contents match, you're good to go.

"Jumping around" in C code would be expected in an optimized build.

Pavel Minaev
  • 99,783
  • 25
  • 219
  • 289