0

I wish I could provide a simple sample case that occurs using standard library code, but unfortunately it only happens when using one of our in-house libraries that in turn is built on top of sql alchemy.

Basically, the problem is that this break command:

(Pdb) print sqlalchemy.engine.base.__file__
/prod/eggs/SQLAlchemy-0.5.5-py2.5.egg/sqlalchemy/engine/base.py

(Pdb) break /prod/eggs/SQLAlchemy-0.5.5-py2.5.egg/sqlalchemy/engine/base.py:946

Is just being totally ignored, it seems, by pdb. As in, even though I am positive the code is being hit (both because I can see log messages, and because I've used sys.settrace to check which lines in which files are being hit), pdb is just not breaking there.

I suspect that somehow the use of an egg is confusing pdb as to what files are being used (I can't reproduce the error if I use a non-egg'ed library, like pickle; there everything works fine).

It's a shot in the dark, but has anyone come across this before?

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
YGA
  • 9,546
  • 15
  • 47
  • 50

3 Answers3

0

What version of python are running? I observe similar behavior on python 2.7.3. Curiously, I do not see the same behavior on ipython 0.12.1.

In python 2.7.3, the debugger and the stack trace get the point where an exception occurred wrong.

In ipython 0.12.1, the debugger and the stack trace get the point where the exception occurs is correct, but once the exception occurs, then the program exits, which makes post mortem debugging difficult.

Jeff Silverman
  • 692
  • 1
  • 8
  • 15
0

I wonder if somehow there's an old .pyc that can't be deleted because of permissions being messed up. Nuke all of the .pycs in your python-path, and see if that helps.

This blog post might be related to your trouble.

Jonathan Feinberg
  • 44,698
  • 7
  • 80
  • 103
0

I don't suppose this is yet another problem caused by setuptools? I ask because I notice the ".egg" in that path...

SamB
  • 9,039
  • 5
  • 49
  • 56