homepage

backtrace (relevant outer frames only):
 File "/path/to/myfile", line 1198, in get_hook_name
 for frame_record in inspect.stack():
 File "/usr/mbench2.2/lib/python2.4/inspect.py", line 819, in stack
 return getouterframes(sys._getframe(1), context)
 File "/usr/mbench2.2/lib/python2.4/inspect.py", line 800, in getouterframes
 framelist.append((frame,) + getframeinfo(frame, context))
 File "/usr/mbench2.2/lib/python2.4/inspect.py", line 775, in getframeinfo
 lines, lnum = findsource(frame)
 File "/usr/mbench2.2/lib/python2.4/inspect.py", line 437, in findsource
 if pat.match(lines[lnum]): break
IndexError: list index out of range
Based on a quick look at the inspect code, I think
this happens when you:
 - Start python and load a module
 - While it's running, edit the source file for the
 module (before inspect tries to look into it).
 - Call a routine in the edited module that will
 lead to a call to inspect.stack().
During an inspect.stack() call, inspect will open
source files to get the source code for the
routines on the stack. If the source file that is
opened doesn't match the byte compiled code that's
being run, there are problems. Inspect caches the
files it reads (using the linecache module), so if
the file gets cached before it is edited, nothing
should go wrong. But if the source file is edited
after the module is loaded and before inspect has
a chance to cache the source, you're out of luck.
Of course, this shouldn't be a problem in production
code, but it has bit us more than once in a
development environment.
Seems like it would be easy to avoid by just comparing
the timestamps on the source/object files. If the
source file is newer, just behave the same as if it
wasn't there.
Attached is a stupid little python script that
reproduces the problem.