Closed betaprior closed 4 years ago
It's preferred to C-c C-o
directly from a raw .ipynb file to open it in EIN, but either way, it shouldn't crash.
Below is my attempt on emacs-26.3. It did take more than ten seconds for EIN to open, which is pretty bad, but I didn't see the crash.
My bad, jumped the gun on this; my 26.3 instance pegged the CPU for 30 minutes but didn't crash. However, under the same conditions / repro steps, 27.090 reliably hits an OOM condition after chewing on the CPU for 5-10 minutes, and 28.050 crashes even faster :) This may have something to do with the new native JSON parser.
It seems that if EIN never sees that ipynb file except when opened by the kernel, things work as expected. However, the fact that a 500 kb ipynb file can crash Emacs under my repro scenario is somewhat worrying.
It's perturbing your 26.3 bogged for 30 minutes. Nonetheless, I am appending the emacs-27 label on this issue as well. Thank you for the bug report.
I retried with emacs-27.1 and did not witness "an OOM condition after chewing on the CPU for 5-10 minutes". You may reopen the issue following the README's instructions for filing a bug, although I suspect you've moved on from EIN.
Generally, emacs has trouble with long lines. In particular, your "this_crashes_emacs.ipynb" is a single line of more than a half million characters. In some sense, EIN is doomed from the start since modern web tools seem to want to "minify" javascript and json into single lines.
Steps to reproduce:
For me, these actions result in emacs consuming all available RAM (16 GB) in seconds, followed by an out-of-memory crash. Reproduced on 27.090, 28.050