All, I have a problem being reported (by Xen users) where inspect.stack() is throwing IndexError. I think that this is a bug in inspect.py -- findsource generally throws IOError when it can't find a particular source file, but in the case where it finds a source file, but that file is shorter than expected, then findsource throws IndexError, and this is propagated all the way out of inspect.stack(). I'm not sure why inspect.py is finding source files that don't match the code being executed -- it seems to be dependent upon the install environment, because it's not affecting most people. That said, I think that it's reasonable to cope with a too-short source file in the same way as we cope with missing source files -- by throwing IOError from findsource and handling that exception later. Here's a patch. Cheers, Ewan Mellor, XenSource. --- inspect.py.orig 2007-03-17 17:01:56.410399391 +0000 +++ inspect.py 2007-03-17 17:16:36.026005726 +0000 @@ -490,6 +490,8 @@ if not hasattr(object, 'co_firstlineno'): raise IOError('could not find function definition') lnum = object.co_firstlineno - 1 + if len(lines) - 1 < lnum: + raise IOError('source file is too short') pat = re.compile(r'^(\s*def\s)|(.*(? 0: if pat.match(lines[lnum]): break
On 3/17/07, Ewan Mellor
I have a problem being reported (by Xen users) where inspect.stack() is throwing IndexError. I think that this is a bug in inspect.py -- findsource generally throws IOError when it can't find a particular source file, but in the case where it finds a source file, but that file is shorter than expected, then findsource throws IndexError, and this is propagated all the way out of inspect.stack().
I'm not sure why inspect.py is finding source files that don't match the code being executed -- it seems to be dependent upon the install environment, because it's not affecting most people. That said, I think that it's reasonable to cope with a too-short source file in the same way as we cope with missing source files -- by throwing IOError from findsource and handling that exception later.
FYI: this has been reported at least once before: see bug #1628987 (http://python.org/sf/1628987). The problem (in the bug report, at least) is that the source file changes between compilation and when findsource() is called, and findsource() picks up the modified version. Collin Winter
On Sat, Mar 17, 2007 at 08:09:06PM -0500, Collin Winter wrote:
On 3/17/07, Ewan Mellor
wrote: I have a problem being reported (by Xen users) where inspect.stack() is throwing IndexError. I think that this is a bug in inspect.py -- findsource generally throws IOError when it can't find a particular source file, but in the case where it finds a source file, but that file is shorter than expected, then findsource throws IndexError, and this is propagated all the way out of inspect.stack().
I'm not sure why inspect.py is finding source files that don't match the code being executed -- it seems to be dependent upon the install environment, because it's not affecting most people. That said, I think that it's reasonable to cope with a too-short source file in the same way as we cope with missing source files -- by throwing IOError from findsource and handling that exception later.
FYI: this has been reported at least once before: see bug #1628987 (http://python.org/sf/1628987). The problem (in the bug report, at least) is that the source file changes between compilation and when findsource() is called, and findsource() picks up the modified version.
Thanks for that. It's certainly a mismatch between the compiled code and the source file subsequently found. That said, I don't think that it only affects the case when people are editing source files and not recompiling -- this isn't the sort of thing that my users would be doing at this point. I suspect that the source file lookup is broken in some way, and so the wrong file ends up in the line cache. It's not affecting me, unfortunately, so I can't easily investigate. I see that you closed this bug as "Won't Fix". My two line patch seems like a reasonable workaround, and certainly more simple than the other proposals -- do you think it's worth dropping in? Cheers, Ewan.
participants (2)
-
Collin Winter
-
Ewan Mellor