millejoh / emacs-ipython-notebook

Jupyter notebook client in Emacs
http://millejoh.github.io/emacs-ipython-notebook/
GNU General Public License v3.0
1.47k stars 122 forks source link

Jupyter notebooks with lots of binary data can crash recent versions of emacs #698

Closed betaprior closed 4 years ago

betaprior commented 4 years ago

Steps to reproduce:

  1. grab this ~500KB ipynb file: https://www.dropbox.com/s/r9vsn3uwuwjlr8n/this_crashes_emacs.ipynb?dl=0
  2. open the ipynb file in emacs (e.g. via C-x C-f)
  3. emacs will probably hang for 1-5 minutes with CPU pegged at 100% as it displays the raw JSON contents of the file
  4. M-x ein:run

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

dickmao commented 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.

issue-698

betaprior commented 4 years ago

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.

dickmao commented 4 years ago

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.

dickmao commented 4 years ago

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.