469,578 Members | 1,933 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,578 developers. It's quick & easy.

pdb in python2.5

Hi,

Maybe I'm repeating a previous post (please correct me if I am).

I've tried the following code in python 2.5 (r25:51908, Oct 6 2006,
15:22:41)
example:

from __future__ import with_statement
import threading

def f():
l = threading.Lock()
with l:
print "hello"
raise Exception("error")
print "world"

try:
f()
except:
import pdb
pdb.pm()

This fails because pdb.pm() attempts to access sys.last_traceback which
is not assigned.
Trying:
pdb.post_mortem(sys.exc_traceback)

Yields the following:
test.py(9)f()
-print "world"
(Pdb)

the 'w' command yields a similar output, which implies that the
exception was thrown from the wrong line.
the traceback module is better, yielding correct results (displays line
8 instead of 9).

Has anyone encountered this behavior? is pdb broken?
I get similar results for larger/more complex pieces of code.

Thanks in advance,

Rotem

Jan 25 '07 #1
5 1495
"Rotem" <vm*****@gmail.comwrites:
Hi,

Maybe I'm repeating a previous post (please correct me if I am).

I've tried the following code in python 2.5 (r25:51908, Oct 6 2006,
15:22:41)
example:

from __future__ import with_statement
import threading

def f():
l = threading.Lock()
with l:
print "hello"
raise Exception("error")
print "world"

try:
f()
except:
import pdb
pdb.pm()

This fails because pdb.pm() attempts to access sys.last_traceback which
is not assigned.
Recent releases of pydb (http://bashdb.sf.net/pydb) don't suffer this
problem. (But see below.)
Trying:
pdb.post_mortem(sys.exc_traceback)

Yields the following:
test.py(9)f()
-print "world"
(Pdb)

the 'w' command yields a similar output, which implies that the
exception was thrown from the wrong line.
the traceback module is better, yielding correct results (displays line
8 instead of 9).

Has anyone encountered this behavior?
Yes, this seems to be a bug in pdb. It is using the traceback's f_line
instance variable rather than the tb_lineno instance variable. I guess
these two values are usually the same. In fact, I haven't been able to
come up with a Python 2.4 situtation where they are different. (If
someone can, I'd appreciate it if you'd send me a small example so I
can put it in the pydb regression tests.) Even in 2.5, it's kind of
hard to get a case where they are different. If I remove the "with",
the problem goes away.

It was also bug in pydb, but I've just committed in CVS the fix for
this

is pdb broken?
Best as I can tell pdb isn't all that well maintained. (Had it been, I
probably wouldn't have devoted the time to pydb that I have been.)
I get similar results for larger/more complex pieces of code.
>
Thanks in advance,

Rotem
Jan 25 '07 #2
I'd like to change my assessment of whether the problem encountered is
a pdb bug or not. It could be a bug in Python. (Right now it is only
known to be a bug in version 2.5.)

For a given traceback t, the question is whether t.tb_frame.f_lineno
can ever be different from t.tb_lineno.

Still, for now in pydb CVS, I've worked around this by checking.

ro***@panix.com (R. Bernstein) writes:
"Rotem" <vm*****@gmail.comwrites:
Hi,

Maybe I'm repeating a previous post (please correct me if I am).

I've tried the following code in python 2.5 (r25:51908, Oct 6 2006,
15:22:41)
example:

from __future__ import with_statement
import threading

def f():
l = threading.Lock()
with l:
print "hello"
raise Exception("error")
print "world"

try:
f()
except:
import pdb
pdb.pm()

This fails because pdb.pm() attempts to access sys.last_traceback which
is not assigned.

Recent releases of pydb (http://bashdb.sf.net/pydb) don't suffer this
problem. (But see below.)
Trying:
pdb.post_mortem(sys.exc_traceback)

Yields the following:
test.py(9)f()
-print "world"
(Pdb)

the 'w' command yields a similar output, which implies that the
exception was thrown from the wrong line.
the traceback module is better, yielding correct results (displays line
8 instead of 9).

Has anyone encountered this behavior?

Yes, this seems to be a bug in pdb. It is using the traceback's f_line
instance variable rather than the tb_lineno instance variable. I guess
these two values are usually the same. In fact, I haven't been able to
come up with a Python 2.4 situtation where they are different. (If
someone can, I'd appreciate it if you'd send me a small example so I
can put it in the pydb regression tests.) Even in 2.5, it's kind of
hard to get a case where they are different. If I remove the "with",
the problem goes away.

It was also bug in pydb, but I've just committed in CVS the fix for
this

is pdb broken?

Best as I can tell pdb isn't all that well maintained. (Had it been, I
probably wouldn't have devoted the time to pydb that I have been.)
I get similar results for larger/more complex pieces of code.

Thanks in advance,

Rotem
Jan 25 '07 #3
Hi,

I noticed that pydb.pm() also fails in python2.5 when invoked on that
same example (seems like also trying to access a nonexistent
attribute/variable).

Is this known to you as well/was it fixed?

On Jan 25, 9:15 pm, r...@panix.com (R. Bernstein) wrote:
I'd like to change my assessment of whether the problem encountered is
a pdb bug or not. It could be a bug in Python. (Right now it is only
known to be a bug in version 2.5.)

For a given traceback t, the question is whether t.tb_frame.f_lineno
can ever be different from t.tb_lineno.

Still, for now in pydb CVS, I've worked around this by checking.

r...@panix.com (R. Bernstein) writes:
"Rotem" <vmal...@gmail.comwrites:
Hi,
Maybe I'm repeating a previous post (please correct me if I am).
I've tried the following code in python 2.5 (r25:51908, Oct 6 2006,
15:22:41)
example:
from __future__ import with_statement
import threading
def f():
l = threading.Lock()
with l:
print "hello"
raise Exception("error")
print "world"
try:
f()
except:
import pdb
pdb.pm()
This fails because pdb.pm() attempts to access sys.last_traceback which
is not assigned.
Recent releases of pydb (http://bashdb.sf.net/pydb) don't suffer this
problem. (But see below.)
Trying:
pdb.post_mortem(sys.exc_traceback)
Yields the following:
test.py(9)f()
-print "world"
(Pdb)
the 'w' command yields a similar output, which implies that the
exception was thrown from the wrong line.
the traceback module is better, yielding correct results (displays line
8 instead of 9).
Has anyone encountered this behavior?
Yes, this seems to be a bug in pdb. It is using the traceback's f_line
instance variable rather than the tb_lineno instance variable. I guess
these two values are usually the same. In fact, I haven't been able to
come up with a Python 2.4 situtation where they are different. (If
someone can, I'd appreciate it if you'd send me a small example so I
can put it in the pydb regression tests.) Even in 2.5, it's kind of
hard to get a case where they are different. If I remove the "with",
the problem goes away.
It was also bug in pydb, but I've just committed in CVS the fix for
this
is pdb broken?
Best as I can tell pdb isn't all that well maintained. (Had it been, I
probably wouldn't have devoted the time to pydb that I have been.)
I get similar results for larger/more complex pieces of code.
Thanks in advance,
Rotem
Jan 25 '07 #4
"Rotem" <vm*****@gmail.comwrites:
Hi,

I noticed that pydb.pm() also fails in python2.5 when invoked on that
same example (seems like also trying to access a nonexistent
attribute/variable).

Is this known to you as well/was it fixed?
Doesn't do that for me for Python 2.5 on both pydb 1.20 (last released
version) and the current CVS. See below. If you think the problem is
not on your end and want to file a bug report, please do. But note

* comp.lang.python is not the place to file bug reports
* more detail is needed that what's been given so far

$ cat /tmp/t1.py
from __future__ import with_statement
import threading

def f():
l = threading.Lock()
with l:
print "hello"
raise Exception("error")
print "world"

try:
f()
except:
import pydb
pydb.pm()
$ python /tmp/t1.py
hello
(/tmp/t1.py:9): f
(Pydb) where
-0 f() called from file '/tmp/t1.py' at line 9
## 1 <module>() called from file '/tmp/t1.py' at line 15
(Pydb) show version
pydb version 1.20.
(Pydb) quit
$ python /tmp/t1.py
hello
(/tmp/t1.py:15): <module>
(Pydb) where
## 0 f() called from file '/tmp/t1.py' at line 8
-1 <module>() called from file '/tmp/t1.py' at line 15
(Pydb) show version
pydb version 1.21cvs.
(Pydb) quit
$
Jan 26 '07 #5
* comp.lang.python is not the place to file bug reports
Agreed
* more detail is needed that what's been given so far
Agreed. I will investigate further when I get a chance and determine if
it's a problem on my end.

Thanks a lot!

Jan 26 '07 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Jakub Moscicki | last post: by
4 posts views Thread by tudor | last post: by
1 post views Thread by km | last post: by
1 post views Thread by Tim N. van der Leeuw | last post: by
15 posts views Thread by Christopher Taylor | last post: by
6 posts views Thread by samn | last post: by
reply views Thread by suresh191 | last post: by
4 posts views Thread by guiromero | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.