ERROR: Internal Python error in the inspect module.

[mwiebe]

Looks like this is related to issue #53. I just got the following in the notebook:

In [33]:

# Switch to NumPy
pw.prtparam = p

Traceback (most recent call last):
  File "C:\Python27\lib\site-packages\ipython-0.13.dev-py2.7.egg\IPython\core\ultratb.py", line 756, in structured_traceback
    records = _fixed_getinnerframes(etb, context, tb_offset)
  File "C:\Python27\lib\site-packages\ipython-0.13.dev-py2.7.egg\IPython\core\ultratb.py", line 242, in _fixed_getinnerframes
    records  = fix_frame_records_filenames(inspect.getinnerframes(etb, context))
  File "C:\Python27\lib\inspect.py", line 1041, in getinnerframes
    framelist.append((tb.tb_frame,) + getframeinfo(tb, context))
  File "C:\Python27\lib\inspect.py", line 1005, in getframeinfo
    lines, lnum = findsource(frame)
  File "C:\Python27\lib\inspect.py", line 578, in findsource
    if pat.match(lines[lnum]): break
IndexError: list index out of range
ERROR: Internal Python error in the inspect module.
Below is the traceback from this internal error.

Unfortunately, your original traceback can not be constructed.

[takluyver]

Aha, this rings a bell...does re-enabling the monkeypatch that was disabled in 1cd5a58 fix it?

Can you provide steps to reproduce this?

[mwiebe]

It happened in a context with a lot of Qt, OpenGL, and PyCUDA going on. There was a bug in my code causing an exception inside the prtparam setter, which was defined like this:

    @property
    def prtparam(self):
        return self._prtparam

    @prtparam.setter
    def prtparam(self, newprtparam):
        if self._prtparam != None:
            self._prtparam.close()
        self._prtparam = newprtparam
        self.prt_view_widget.prtparam = newprtparam

Likely the error was raised from the close() call, which was calling both OpenGL and PyCUDA functions. I was able to repeat it in a few fresh runs, but if I run it with the bug in there now, it produces the perfectly reasonable

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
D:\Develop\notebooks\<ipython-input-15-dec90c4997b5> in <module>()
      1 # Switch to NumPy
----> 2 pw.prtparam = p

D:\Develop\scripts\particle_window.py in prtparam(self, newprtparam)
     53     def prtparam(self, newprtparam):
     54         if self._prtparam != None:
---> 55             self._prtparam.close()
     56         self._prtparam = newprtparam

D:\Develop\scripts\cuda_prt.pyc in close(self)
    142     def close(self):
    143         # Free the particle VBO
--> 144         self.prt = None
    145         # Free the CUDA context
    146         if self._context != None:

D:\Develop\scripts\cuda_prt.pyc in prt(self, newprt)
     59         self.selected_particles = None
     60         # Make sure the GL context is set
---> 61         self._gl_context_fn()
     62 
     63         # Free the existing particle VBO

TypeError: 'NoneType' object is not callable

[takluyver]

Hmmm, so you can no longer reproduce it? Looking at the traceback when it was failing, though, it is failing at the point that our monkeypatch was intended to resolve.

The error is that it's getting a line number beyond the end of the file. I think that might occur if you're changing the file while the module is loaded, so that the loaded line numbers don't match those on disk.

[mwiebe]

No, it's not happening now, but your thought about changing the file makes good sense. The close() function is at the very end of cuda_prt.py, and I've done

%load_ext autoreload
%autoreload 2

so that it automatically updates when I change stuff.

[takluyver]

OK, perhaps we have to re-enable the monkeypatch. I'd prefer to catch the error when it reaches our own code, so we benefit from upstream changes to inspect. I'll play around and see if I can reproduce it by editing files.

[nealmcb]

I got the same error in Ubuntu 12.04 (precise) with ipython 0.12.1+dfsg-0ubuntu1 when repeatedly editing a python file and running it in ipython sort of like this:

In [423]: run aiclass22_nlp.py

In [424]: p = main()

edit... edit...

In [425]: run aiclass22_nlp.py

In [426]: p = main()
ERROR: Internal Python error in the inspect module.
Below is the traceback from this internal error.
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/IPython/core/ultratb.py", line 756, in structured_traceback
records = _fixed_getinnerframes(etb, context, tb_offset)
File "/usr/lib/python2.7/dist-packages/IPython/core/ultratb.py", line 242, in _fixed_getinnerframes
records = fix_frame_records_filenames(inspect.getinnerframes(etb, context))
File "/usr/lib/python2.7/inspect.py", line 1043, in getinnerframes
framelist.append((tb.tb_frame,) + getframeinfo(tb, context))
File "/usr/lib/python2.7/inspect.py", line 1007, in getframeinfo
lines, lnum = findsource(frame)
File "/usr/lib/python2.7/inspect.py", line 580, in findsource
if pat.match(lines[lnum]): break
IndexError: list index out of range

Unfortunately, your original traceback can not be constructed.

[takluyver]

I've assigned this to myself to try to reproduce the error.

[takluyver]

OK, I've got a reproducible case - Create a file test.py with:

1
2
3
def f():
    1/0

Then %run or import it in IPython, and call f() to get the ZeroDivisionError.

Now edit the file to remove the 1 2 3 lines, and without re-running/re-importing, call f() twice more in IPython, which results in this:

In [5]: f()
---------------------------------------------------------------------------
ZeroDivisionError                         Traceback (most recent call last)
<ipython-input-5-0ec059b9bfe1> in <module>()
----> 1 f()

/home/thomas/scratch/test.py in f()
      3 

ZeroDivisionError: integer division or modulo by zero

In [6]: f()
ERROR: Internal Python error in the inspect module.
Below is the traceback from this internal error.
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/IPython/core/ultratb.py", line 756, in structured_traceback
    records = _fixed_getinnerframes(etb, context, tb_offset)
  File "/usr/lib/python2.7/dist-packages/IPython/core/ultratb.py", line 242, in _fixed_getinnerframes
    records  = fix_frame_records_filenames(inspect.getinnerframes(etb, context))
  File "/usr/lib/python2.7/inspect.py", line 1043, in getinnerframes
    framelist.append((tb.tb_frame,) + getframeinfo(tb, context))
  File "/usr/lib/python2.7/inspect.py", line 1007, in getframeinfo
    lines, lnum = findsource(frame)
  File "/usr/lib/python2.7/inspect.py", line 580, in findsource
    if pat.match(lines[lnum]): break
IndexError: list index out of range

Unfortunately, your original traceback can not be constructed.

Why it's only the second call that fails, I don't know. I'll try to work up a proper test case for this, and then a fix.

[rainwoodman]

On a freshly installed 0.13, I am able to reproduce the bug with the following code:

L = {}
eval(compile(
"""
def func():
1 / 0
""", '', 'exec', 0, True), L)

f = L['func']
f()

The problem is that the filename supplied to the compile function is an empty string, and inspect.getfile doesn't like an empty filename. If I use '<>' as the filename the backtrace in ipython is fine.

[takluyver]

@rainwoodman That sounds like a related but different bug. If you can reproduce it in master, can you open a new issue for it?

[merwok]

This sounds like it could be related to the use of linecache in the inspect module.

[jhallard]

Did this ever get fixed? I just saw this start to pop up randomly in an application I'm working on. Partial stack-trace below, removing functions/data that I'm not at liberty to share.

      File "safelog.py", line 133, in <lambda>
        return (lambda text, *args: self.writelog(name, text, args))
      File "safelog.py", line 56, in writelog
        calframe = inspect.getouterframes(inspect.currentframe())
      File "/usr/lib/python2.7/inspect.py", line 1038, in getouterframes
        framelist.append((frame,) + getframeinfo(frame, context))
      File "/usr/lib/python2.7/inspect.py", line 1013, in getframeinfo
        lines, lnum = findsource(frame)
      File "/usr/lib/python2.7/inspect.py", line 580, in findsource
        if pat.match(lines[lnum]): break
    IndexError: list index out of range

[xtknight]

Actually I just got it too when using the wide and deep learning example code with TensorFlow using CUDA. I made a code modification to using training and testing data from the local FS and removed the maybe_download function and saved the py file fast, running the script again. It happened at that point. I thought maybe somehow the file system was out of sync and Python got a handle of an old file and couldn't find the line number. It only happened once so far.

Traceback (most recent call last):
  File "wide_n_deep_tutorial.py", line 207, in <module>
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/platform/app.py", line 43, in run
    sys.exit(main(sys.argv[:1] + flags_passthrough))
  File "wide_n_deep_tutorial.py", line 203, in main
  File "wide_n_deep_tutorial.py", line 197, in train_and_eval
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/contrib/learn/python/learn/estimators/dnn_linear_combined.py", line 725, in evaluate
    steps=steps, metrics=metrics, name=name)
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/util/deprecation.py", line 189, in new_func
    _call_location(), decorator_utils.get_qualified_name(func),
  File "/usr/local/lib/python3.5/dist-packages/tensorflow/python/util/deprecation.py", line 61, in _call_location
    stack = inspect.stack()
  File "/usr/lib/python3.5/inspect.py", line 1464, in stack
    return getouterframes(sys._getframe(1), context)
  File "/usr/lib/python3.5/inspect.py", line 1441, in getouterframes
    frameinfo = (frame,) + getframeinfo(frame, context)
  File "/usr/lib/python3.5/inspect.py", line 1414, in getframeinfo
    lines, lnum = findsource(frame)
  File "/usr/lib/python3.5/inspect.py", line 804, in findsource
    if pat.match(lines[lnum]): break
IndexError: list index out of range

Edit: there's a chance I accidentally saved the script while a previous one was running and the error was from the previous execution. This is what happened when it occurred again.

[EPedrotti]

Was this ever fixed? Is there a way around this problem?