ipython 8+ python crash on exception #13598
Comments
|
Which version of IPython is this? There were at least 4 releases in 8.. series, IIRC some of them aimed at patching similar issues. |
|
|
|
The previous 8-series versions had the same issue. |
|
Do you have a minimal set of steps to reproduce this? If you're using autoreload it might be specific to the code you are reloading. |
|
Unfortunately all I can show is the tracebacks. I seems to be related to autoreload that involves data current objects. Usually of rather complex data objects, |
|
another example: Then Ipython terminates and I have to start over again. |
|
It seems to be related to |
|
which version of |
|
I use the current versions from pip
|
|
the last error always seems to come from |
|
Stack data and executing have been developed originally for this purpose.
So there won’t be more stable/better debugged packages.
…On Mon, Mar 21, 2022 at 3:12 PM Alexander Heger ***@***.***> wrote:
the last error always seems to come from executing - maybe this needs to
be replaced by a properly debugged package?
File "/home/alex/Python/lib/python3.10/site-packages/executing/executing.py", line 164, in only
raise NotOneValueFound('Expected one value, found 0')
executing.executing.NotOneValueFound: Expected one value, found 0
—
Reply to this email directly, view it on GitHub
<#13598 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACR5TZ2DWZXVCQJV75EXQ3VBB7TVANCNFSM5RFBSRPQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Hmm, it seems it was not successful then. I see many dozens of these per day: Should I switch to an earlier version? Can it be disabled? |
|
I installed Version 0.7.0, still fails. Maybe to replace the |
|
that did not help, now I end up with |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
I have this issue too with IPython 8.1.1, on a Pop OS machine. It seems like the error message is essentially identical to #13586. For the moment, I just reset ipython every few mins during debugging. |
|
@Carreau did you mark my comment as off-topic with no other engagement? Why? I tried to provide some detailed information that ipython v8 is not compatible with jupyter. |
|
I want to +1 the relevance of @brandondube 's report to this issue. So at the very least this gives scope to the impact of the bug, and allows searchers like myself to find this issue and figure out that's the underlying cause. |
|
I get the same long stream of errors that end with "executing.executing.NotOneValueFound: Expected one value, found 0" on windows with ipython 8.4.0 (python 3.9.2). I just start ipython, import, edit, re-import and at some point when my script raises an error I get it. |
|
Here's a repro for this. On my system I was able to consistently trigger this type of exception by importlib.reload'ing a module. It seems ipython gets confused when the module changes on disk and the old source location of the error does not align with the new source location. I can imagine that running conda/pip/other package managers while ipython is running may also cause this issue. I'm running jupyterlab 3.4.3, jupyter-nbclassic 0.3.7, jupyter-notebook 6.4.12, and python 3.10.5 on Arch Linux x86_64. To reproduce, run these three ipython cells in order: Cell 1 import importlib
import sys
from pathlib import Path
tmpdir = Path('/tmp/traceback_exc_test')
tmpdir.mkdir(exist_ok=True)
sys.path.append(str(tmpdir))
(tmpdir / 'ipy_err_test_module.py').write_text('print("imported version 1")\ndef crash_and_burn():\n raise ValueError()')
import ipy_err_test_module
try:
ipy_err_test_module.crash_and_burn()
except:
passOutput: Cell 2 (tmpdir / 'ipy_err_test_module.py').write_text('print("imported version 2")\n\n\ndef crash_and_burn():\n raise SystemError()')
importlib.reload(ipy_err_test_module)
ipy_err_test_module.crash_and_burn()Output: Cell 3 (tmpdir / 'ipy_err_test_module.py').write_text('print("imported version 2")\n\n\n\n\n\n\ndef crash_and_burn():\n raise SystemError()')
importlib.reload(ipy_err_test_module)
ipy_err_test_module.crash_and_burn()Output: |
|
A simple reproducer we came across for this type of error: |
|
Hi all. Author of First of all, please @ me or open an issue on stack_data in cases like this. It's a bit weird seeing so many people clearly very annoyed about this but no one telling me about it. I'm not watching IPython's issue tracker so I have no way of knowing, I just happened to stumble across this now. This isn't even the first time I've discovered an issue in this way. @Carreau especially please ping me sooner. I see the traceback always ends like this: File "/usr/lib/python3.10/site-packages/stack_data/core.py", line 628, in executing_piece
return only(
File "/usr/lib/python3.10/site-packages/executing/executing.py", line 164, in only
raise NotOneValueFound('Expected one value, found 0')
executing.executing.NotOneValueFound: Expected one value, found 0
In the meantime, I suggest running this code: import stack_data
stack_data.Source.for_filename(filename, use_cache=False)for all reloaded files/modules immediately after reloading them. |
|
@alexmojaki A way to catch reloading modules would be to insert a IMHO this solution is pretty minimally invasive, as it does not mess around with python's actual importing machinery. Here's a demo: import importlib
import importlib.abc
import sys
class PrintFinder(importlib.abc.MetaPathFinder):
def find_spec(fullname, path, target=None):
if target:
print(' reloading', fullname, path, target)
# drop caches here
sys.meta_path.insert(0, PrintFinder)
print('=== Initial import ===')
import requests
print('=== Reload ===')
importlib.reload(requests)Output: |
|
Thanks @jaseg for the great suggestion. I've implemented and released it. Everyone: |
|
We should be mindful that if someone installs another MetaPathFinder at index zero after executing has done its thing, then this workaround would not work when reloading modules provided by that Finder. It’s probably a small minority of cases but it makes this a workaround, not a complete solution. I was wondering if there is any place where we can check the identity of the cached module compared to the item in sys.modules, and flush the cache when the identity is not the same? |
|
I agree that it is still possible to break this solution, but there are some mitigating factors at play and I think the practical risk is very low.
|
|
Just another data point: I'm seeing this with regular old iPython command line, outside Jupyter. I am not doing any reloading magic by hand, but get this from the Curiously, after starting up iPython, |
|
Does this happen even if you don't change the python file between runs? |
|
I actually hadn't noticed -- the whole point of re-running was that. I changed it :-) But testing now, you're insight is right -- it only happens if I change the file, and sometimes not then, depending on the change. I haven't tested carefully, but I think it happens when I add or remove lines before where the exception occurs. |
|
Nothing to add other than a +1, this issue happens very frequently working in vscode python interactive terminal with executing = 0.10.0 During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/Users/jayme/Library/Caches/pypoetry/virtualenvs/jambot-B_1U8XU9-py3.9/lib/python3.9/site-packages/IPython/core/interactiveshell.py", line 1993, in showtraceback
stb = self.InteractiveTB.structured_traceback(
File "/Users/jayme/Library/Caches/pypoetry/virtualenvs/jambot-B_1U8XU9-py3.9/lib/python3.9/site-packages/IPython/core/ultratb.py", line 1118, in structured_traceback
return FormattedTB.structured_traceback(
File "/Users/jayme/Library/Caches/pypoetry/virtualenvs/jambot-B_1U8XU9-py3.9/lib/python3.9/site-packages/IPython/core/ultratb.py", line 1012, in structured_traceback
return VerboseTB.structured_traceback(
File "/Users/jayme/Library/Caches/pypoetry/virtualenvs/jambot-B_1U8XU9-py3.9/lib/python3.9/site-packages/IPython/core/ultratb.py", line 865, in structured_traceback
formatted_exception = self.format_exception_as_a_whole(etype, evalue, etb, number_of_lines_of_context,
File "/Users/jayme/Library/Caches/pypoetry/virtualenvs/jambot-B_1U8XU9-py3.9/lib/python3.9/site-packages/IPython/core/ultratb.py", line 818, in format_exception_as_a_whole
frames.append(self.format_record(r))
File "/Users/jayme/Library/Caches/pypoetry/virtualenvs/jambot-B_1U8XU9-py3.9/lib/python3.9/site-packages/IPython/core/ultratb.py", line 736, in format_record
result += ''.join(_format_traceback_lines(frame_info.lines, Colors, self.has_colors, lvals))
File "/Users/jayme/Library/Caches/pypoetry/virtualenvs/jambot-B_1U8XU9-py3.9/lib/python3.9/site-packages/stack_data/utils.py", line 145, in cached_property_wrapper
value = obj.__dict__[self.func.__name__] = self.func(obj)
File "/Users/jayme/Library/Caches/pypoetry/virtualenvs/jambot-B_1U8XU9-py3.9/lib/python3.9/site-packages/stack_data/core.py", line 699, in lines
pieces = self.included_pieces
File "/Users/jayme/Library/Caches/pypoetry/virtualenvs/jambot-B_1U8XU9-py3.9/lib/python3.9/site-packages/stack_data/utils.py", line 145, in cached_property_wrapper
value = obj.__dict__[self.func.__name__] = self.func(obj)
File "/Users/jayme/Library/Caches/pypoetry/virtualenvs/jambot-B_1U8XU9-py3.9/lib/python3.9/site-packages/stack_data/core.py", line 647, in included_pieces
pos = scope_pieces.index(self.executing_piece)
File "/Users/jayme/Library/Caches/pypoetry/virtualenvs/jambot-B_1U8XU9-py3.9/lib/python3.9/site-packages/stack_data/utils.py", line 145, in cached_property_wrapper
value = obj.__dict__[self.func.__name__] = self.func(obj)
File "/Users/jayme/Library/Caches/pypoetry/virtualenvs/jambot-B_1U8XU9-py3.9/lib/python3.9/site-packages/stack_data/core.py", line 626, in executing_piece
return only(
File "/Users/jayme/Library/Caches/pypoetry/virtualenvs/jambot-B_1U8XU9-py3.9/lib/python3.9/site-packages/executing/executing.py", line 164, in only
raise NotOneValueFound('Expected one value, found 0')
executing.executing.NotOneValueFound: Expected one value, found 0 |
|
Thanks for the report @jaymegordo. It's interesting that you're still experiencing with the combination of the latest In any case, I have a plan for a completely general solution, which wouldn't rely on a MetaPathFinder and would include situations that don't involve reloading modules like @ChrisBarker-NOAA repeatedly running files. I should have it done this weekend. |
|
New fix is released in |
|
Based on the reactions above and the lack of further comments, I think this and #13586 can be closed? |
|
@alexmojaki I want to report that this bugfix fixed my significant autoreload problems. Many thanks! The pattern was this infamous message: PS: Please also note this trivial autoreload bugfix for python3 required kwargs: #14145 |
|
Greetings all! I'm just a random developer that ran into this bug and @alexmojaki said that the fix was in |
|
The |
|
Um, yeah? It was because I encountered this error in my notebook that I googled this issue. However, I have already restarted linux and this error has disappeared 😆 so I cannot send a screenshot of this error. |
|
Just encountered this in fairly current IPython, this env has: Went away on restart kernel + clear all outputs, sorry to not have any more concrete repro info. (Edit: to clarify, the context was fairly chaotic, was actually debugging repr code for an exception class that in my code is triggered via a magic -- so lots of restarting + raising in a non-recoverable sequence. Exactly the sort of scenario where you'd expect a bug like this to pop up if it can, but not helpful for repro.) |
|
Just bumped into the same error using IPython directly from terminal and pressing ctrl-c to stop a loop printing solutions to an equation. 8/10 the loop terminates normally (KeyboardInterrupt), but 2/10 I get the following instead: I am using Arch ... |
|
Adding a comment here as I also got this error. Restarting the kernel seems to be the only way out. |
|
Faced the same issue with: I still don't understand the source of the problem though. Will update this comment as I find new evidence. |
|
That's not the latest version of executing. I think conda or something weirdly uses an old version of executing when installing IPython. |
This is a workaround for ipython#13598, It does not fix the root cause, but should prevent IPython crash. Worst case it should just not show the relevant frame
This is a workaround for #13598, It does not fix the root cause, but should prevent IPython crash. Worst case it should just not show the relevant frame
Since version 8 in Ipython I frequently - very frequently - get IPython crashes (termination) of the kind below.
I think the specific situation is that I edit code, I use autoreload(3), there is a bug, but when IPython tries traceback it crashes and terminates. Since a main point of using IPython is the auto-reload, this makes it almost unusable for development compared to Version 7.x.x. (Certainly distracting enough to spend the time to finally post it here.)
I have seen there is a few other bugs of that kind reported, but I was not sure which would be similar enough to any of them, hence I post this separately. My apologies for any duplications.
I am not sure whether the error is strictly reproducible as it happens in situations when code is edited.
I use Python 3.10.2 built from source on Linux (Fedora 34).
I am using pylab mode which loads matplotlib, I am not sure whether their event loop may interfere with IPython.
Just a thought.
The text was updated successfully, but these errors were encountered: