--- Begin Message ---
|
Subject: |
27.1; json-pretty-print-buffer on ~2MB line causes core dump |
|
Date: |
Thu, 20 Aug 2020 01:50:55 +1200 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 |
(I presume this is to do with the native JSON support, as Emacs 26.3
copes fine with the same command on the example files.)
Using the example JSON file from
https://emacs.stackexchange.com/questions/598/how-do-i-prevent-extremely-long-lines-making-emacs-slow
which you can fetch with:
wget
https://github.com/Wilfred/ReVo-utilities/blob/a4bdc40dd2656c496defc461fc19c403c8306d9f/revo-export/dictionary.json?raw=true
-O one_line.json
and then safely open in Emacs 27 with:
emacs -Q -f global-so-long-mode one_line.json
C-x C-q to make the buffer writeable.
M-x json-pretty-print-buffer
On my system, Emacs hangs for quite a while and then core dumps.
That's an 18MB line. If I trim it down to ~2MB I still see the same
thing. You can do that with (write-region 1 2000151 "two_mb.json")
and then appending a single '}' at the end of the new file to make
it valid JSON.
If I trim back to ~1MB the command succeeds.
(write-region 1 1000088 "one_mb.json") and then append '}]}}'
The smaller files are a bit nicer for comparisons with Emacs 26.3,
which *does* cope with the 18MB file, but processes the smaller ones
much faster (and much faster than it takes Emacs 27.1 to fail).
I also note that, when forgetting to toggle the read-only buffer
state first, Emacs 26.3 immediately issues the "json-pretty-print:
Buffer is read-only" error, whereas Emacs 27.1 evidentially tries
to do all the work, and (for a file small enough to not cause it
to crash in the process) only notices the buffer read-only state
once it tries to replace the contents "replace-region-contents:
Buffer is read-only".
-Phil
p.s. If you're unable to replicate this and wish me to use gdb,
please give step by step instructions for the entire process.
In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2020-08-12 built on shodan
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Ubuntu 18.04.5 LTS
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit [2 times]
Loading json...done
delete-backward-char: Text is read-only [2 times]
Quit [2 times]
Mark activated
Configured using:
'configure --prefix=/home/phil/emacs/27.1/usr/local
--with-x-toolkit=lucid --without-sound'
Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG DBUS GSETTINGS GLIB NOTIFY INOTIFY
GNUTLS LIBXML2 FREETYPE HARFBUZZ XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11
XDBE XIM MODULES THREADS JSON PDUMPER LCMS2 GMP
Important settings:
value of $LANG: en_NZ.UTF-8
locale-coding-system: utf-8-unix
Major mode: Dired by name
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr json map emacsbug message rmc puny format-spec
rfc822 mml easymenu mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs text-property-search time-date subr-x seq
byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils dired
dired-loaddefs advice tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core term/tty-colors frame
minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite charscript charprop case-table epa-hook jka-cmpr-hook help
simple abbrev obarray cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 50018 10992)
(symbols 48 6273 1)
(strings 32 17137 1060)
(string-bytes 1 545762)
(vectors 16 9965)
(vector-slots 8 132814 16180)
(floats 8 26 42)
(intervals 56 300 0)
(buffers 1000 14))
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#42931: 27.1; json-pretty-print-buffer on ~2MB line causes core dump |
|
Date: |
Tue, 25 Aug 2020 11:19:04 -0700 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
On 8/24/20 11:12 PM, Eli Zaretskii wrote:
What about "normal" Emacs builds? They usually have between 2MB and
8MB of stack. Should we worry about stack overflow in these cases?
No. On x86-64 Ubuntu 18.04.5 each recursion level consumes 304 bytes. Dividing 2
MB by 304 gives you 6578 stack frames, which means the algorithm could handle a
vector of 2**6578 entries, which can't exist anywhere in the known physical
universe.
On real machines it'd have to be reeeeally tiny stack for this recursion to be a
significant problem now, so tiny that Emacs would crash for countless other
reasons. I'll take the liberty of closing the bug report.
--- End Message ---