From unknown Wed Jun 18 23:10:38 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#42931 <42931@debbugs.gnu.org> To: bug#42931 <42931@debbugs.gnu.org> Subject: Status: 27.1; json-pretty-print-buffer on ~2MB line causes core dump Reply-To: bug#42931 <42931@debbugs.gnu.org> Date: Thu, 19 Jun 2025 06:10:38 +0000 retitle 42931 27.1; json-pretty-print-buffer on ~2MB line causes core dump reassign 42931 emacs submitter 42931 Phil Sainty severity 42931 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 19 09:51:09 2020 Received: (at submit) by debbugs.gnu.org; 19 Aug 2020 13:51:09 +0000 Received: from localhost ([127.0.0.1]:38645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8OUe-0006FE-Fl for submit@debbugs.gnu.org; Wed, 19 Aug 2020 09:51:09 -0400 Received: from lists.gnu.org ([209.51.188.17]:46528) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8OUZ-0006Ez-32 for submit@debbugs.gnu.org; Wed, 19 Aug 2020 09:51:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34100) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k8OUY-0005Ib-NZ for bug-gnu-emacs@gnu.org; Wed, 19 Aug 2020 09:51:02 -0400 Received: from smtp-2.orcon.net.nz ([60.234.4.43]:47493) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k8OUV-0003XJ-VV for bug-gnu-emacs@gnu.org; Wed, 19 Aug 2020 09:51:02 -0400 Received: from [101.53.216.96] (port=27757 helo=[192.168.20.103]) by smtp-2.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1k8OUQ-0003O3-LE for bug-gnu-emacs@gnu.org; Thu, 20 Aug 2020 01:50:55 +1200 To: bug-gnu-emacs@gnu.org From: Phil Sainty Subject: 27.1; json-pretty-print-buffer on ~2MB line causes core dump Message-ID: <0b9da4d7-ca24-8e00-d49f-7630e42abe89@orcon.net.nz> 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 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-GeoIP: NZ Received-SPF: pass client-ip=60.234.4.43; envelope-from=psainty@orcon.net.nz; helo=smtp-2.orcon.net.nz X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/19 08:52:16 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) (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)) From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 19 10:15:55 2020 Received: (at 42931) by debbugs.gnu.org; 19 Aug 2020 14:15:55 +0000 Received: from localhost ([127.0.0.1]:40625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8Osc-0001yp-BP for submit@debbugs.gnu.org; Wed, 19 Aug 2020 10:15:55 -0400 Received: from quimby.gnus.org ([95.216.78.240]:45890) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8OsZ-0001r8-Ri for 42931@debbugs.gnu.org; Wed, 19 Aug 2020 10:15:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=swNbXVWC8aVTm8LEIauzW5c/w1BHLvRerDgMaaW72xE=; b=KLY5z/iKcXSpjeWxlPaXAQfa2F DvIOwtF2OnMrbtNPdaIS1ujgczxhezpIl1q3Jbi6W0vaHhxjnWZHwVKaxytOkvnSySSr3X/2NYLmy 3cwRURkr14LFRKeFSfPPKaCD5NHreRVqAN2z1Ispu2mhIHUIAMaaJRh+IacN2kpXgXMM=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k8OsO-0005dQ-Qf; Wed, 19 Aug 2020 16:15:45 +0200 From: Lars Ingebrigtsen To: Phil Sainty Subject: Re: bug#42931: 27.1; json-pretty-print-buffer on ~2MB line causes core dump References: <0b9da4d7-ca24-8e00-d49f-7630e42abe89@orcon.net.nz> X-Now-Playing: Pieter Nooten & Michael Brook's _Sleeps With The Fishes_: "Clouds" Date: Wed, 19 Aug 2020 16:15:38 +0200 In-Reply-To: <0b9da4d7-ca24-8e00-d49f-7630e42abe89@orcon.net.nz> (Phil Sainty's message of "Thu, 20 Aug 2020 01:50:55 +1200") Message-ID: <87364i2039.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Phil Sainty writes: > On my system, Emacs hangs for quite a while and then core dumps. I can confirm that this leads to a segmentation fault (on Debian). Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 42931 Cc: 42931@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Phil Sainty writes: > On my system, Emacs hangs for quite a while and then core dumps. I can confirm that this leads to a segmentation fault (on Debian). [Current thread is 1 (Thread 0x7fbbb1c04000 (LWP 2154403))] (gdb) bt #0 raise (sig=) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x000055d08b0a0ac9 in terminate_due_to_signal (sig=sig@entry=11, backtrace_limit=backtrace_limit@entry=40) at emacs.c:408 #2 0x000055d08b0a0f5f in handle_fatal_signal (sig=sig@entry=11) at sysdep.c:1786 #3 0x000055d08b19bf9d in deliver_thread_signal (sig=sig@entry=11, handler=0x55d08b0a0f54 ) at sysdep.c:1760 #4 0x000055d08b19c019 in deliver_fatal_thread_signal (sig=11) at sysdep.c:1883 #5 handle_sigsegv (sig=11, siginfo=, arg=) at sysdep.c:1883 #6 0x00007fbbb530d140 in () at /lib/x86_64-linux-gnu/libpthread.so.0 #7 0x000055d08b1f7a43 in compareseq (xoff=xoff@entry=897, xlim=xlim@entry=17383858, yoff=yoff@entry=1353, ylim=ylim@entry=25500750, find_minimal=false, ctxt=ctxt@entry=0x7fff5bfa5610) at ../lib/diffseq.h:472 #8 0x000055d08b1f7d94 in compareseq (xoff=, xoff@entry=897, xlim=xlim@entry=17383882, yoff=yoff@entry=1353, ylim=ylim@entry=25500806, find_minimal=false, ctxt=ctxt@entry=0x7fff5bfa5610) at ../lib/diffseq.h:510 #9 0x000055d08b1f7d94 in compareseq (xoff=, xoff@entry=897, xlim=xlim@entry=17383917, yoff=yoff@entry=1353, ylim=ylim@en try=25500849, find_minimal=false, ctxt=ctxt@entry=0x7fff5bfa5610) at ../lib/diffseq.h:510 #10 0x000055d08b1f7d94 in compareseq (xoff=, xoff@entry=897, xlim=xlim@entry=17383963, yoff=yoff@entry=1353, ylim=ylim@entry=25500881, find_minimal=false, ctxt=ctxt@entry=0x7fff5bfa5610) at ../lib/diffseq.h:510 #11 0x000055d08b1f7d94 in compareseq (xoff=, xoff@entry=897, xlim=xlim@entry=17384016, yoff=yoff@entry=1353, ylim=ylim@entry=25500898, find_minimal=false, ctxt=ctxt@entry=0x7fff5bfa5610) at ../lib/diffseq.h:510 #12 0x000055d08b1f7d94 in compareseq (xoff=, xoff@entry=897, xlim=xlim@entry=17384024, yoff=yoff@entry=1353, ylim=ylim@entry=25500964, find_minimal=false, ctxt=ctxt@entry=0x7fff5bfa5610) at ../lib/diffseq.h:510 down to... Wow, that's a long backtrace. Hm. Is gdb inflooping? Is that possible? No, it finished: #36798 0x000055d08b1f7db9 in compareseq (xoff=, xoff@entry=146, xlim=xlim@entry=18922266, yoff=yoff@entry=186, ylim=ylim@entry=27160236, find_minimal=false, ctxt=ctxt@entry=0x7fff5bfa5610) at ../lib/diffseq.h:512 #36799 0x000055d08b1f7d94 in compareseq (xoff=, xoff@entry=146, xlim=xlim@entry=18922364, yoff=yoff@entry=186, ylim=ylim@entry=27160398, find_minimal=find_minimal@entry=false, ctxt=ctxt@entry=0x7fff5bfa5610) at ../lib/diffseq.h:510 #36800 0x000055d08b1f7db9 in compareseq (xoff=, xoff@entry=0, xlim=18922364, xlim@entry=18922365, yoff=1, yoff@entry=0, ylim=27160398, ylim@entry=27160399, find_minimal=find_minimal@entry=false, ctxt=ctxt@entry=0x7fff5bfa5610) at ../lib/diffseq.h:512 #36801 0x000055d08b1f8973 in Freplace_buffer_contents (source=0x55d08c598035, max_secs=, max_costs=) at editfns.c:2038 #36802 0x000055d08b1fd493 in Ffuncall (nargs=4, args=args@entry=0x7fff5bfa5758) at lisp.h:2091 #36803 0x000055d08b237a58 in exec_byte_code (bytestr=, vector=, maxdepth=, args_template=, nargs=, args=) at bytecode.c:632 #36804 0x000055d08b1fd3f7 in Ffuncall (nargs=6, args=args@entry=0x7fff5bfa5ac8) at eval.c:2809 #36805 0x000055d08b237a58 in exec_byte_code (bytestr=, vector=, maxdepth=, args_template=, nargs=, args=) at bytecode.c:632 36806 0x000055d08b1fd3f7 in Ffuncall (nargs=4, args=args@entry=0x7fff5bfa5e10) at eval.c:2809 #36807 0x000055d08b237a58 in exec_byte_code (bytestr=, vector=, maxdepth=, args_template=, nargs=, args=) at bytecode.c:632 #36808 0x000055d08b1fd3f7 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fff5bfa6148) at eval.c:2809 #36809 0x000055d08b1f9f91 in Ffuncall_interactively (nargs=2, args=0x7fff5bfa6148) at callint.c:253 #36810 0x000055d08b1fd493 in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7fff5bfa6140) at lisp.h:2091 #36811 0x000055d08b1fb216 in Fcall_interactively (function=0xde4130, record_flag=0xb3d0, keys=0x55d08c597c05) at callint.c:779 OK, so it's not a jansson-related thing, but bugging out in replace-buffer-contents. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 19 11:18:55 2020 Received: (at 42931) by debbugs.gnu.org; 19 Aug 2020 15:18:56 +0000 Received: from localhost ([127.0.0.1]:40761 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8Prb-00079d-LO for submit@debbugs.gnu.org; Wed, 19 Aug 2020 11:18:55 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51540) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8PrZ-00079R-Sg for 42931@debbugs.gnu.org; Wed, 19 Aug 2020 11:18:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50059) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k8PrU-0008Ap-FM; Wed, 19 Aug 2020 11:18:48 -0400 Received: from [176.228.60.248] (port=3661 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k8PrT-0005li-Rv; Wed, 19 Aug 2020 11:18:48 -0400 Date: Wed, 19 Aug 2020 18:18:38 +0300 Message-Id: <831rk2eka9.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87364i2039.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 19 Aug 2020 16:15:38 +0200) Subject: Re: bug#42931: 27.1; json-pretty-print-buffer on ~2MB line causes core dump References: <0b9da4d7-ca24-8e00-d49f-7630e42abe89@orcon.net.nz> <87364i2039.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 42931 Cc: psainty@orcon.net.nz, 42931@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Date: Wed, 19 Aug 2020 16:15:38 +0200 > Cc: 42931@debbugs.gnu.org > > Phil Sainty writes: > > > On my system, Emacs hangs for quite a while and then core dumps. > > I can confirm that this leads to a segmentation fault (on Debian). > > [Current thread is 1 (Thread 0x7fbbb1c04000 (LWP 2154403))] > (gdb) bt > #0 raise (sig=) at ../sysdeps/unix/sysv/linux/raise.c:50 > #1 0x000055d08b0a0ac9 in terminate_due_to_signal > (sig=sig@entry=11, backtrace_limit=backtrace_limit@entry=40) at emacs.c:408 > #2 0x000055d08b0a0f5f in handle_fatal_signal (sig=sig@entry=11) > at sysdep.c:1786 > #3 0x000055d08b19bf9d in deliver_thread_signal > (sig=sig@entry=11, handler=0x55d08b0a0f54 ) > at sysdep.c:1760 > #4 0x000055d08b19c019 in deliver_fatal_thread_signal (sig=11) at sysdep.c:1883 > #5 handle_sigsegv (sig=11, siginfo=, arg=) > at sysdep.c:1883 > #6 0x00007fbbb530d140 in () > at /lib/x86_64-linux-gnu/libpthread.so.0 > #7 0x000055d08b1f7a43 in compareseq > (xoff=xoff@entry=897, xlim=xlim@entry=17383858, yoff=yoff@entry=1353, ylim=ylim@entry=25500750, find_minimal=false, ctxt=ctxt@entry=0x7fff5bfa5610) > at ../lib/diffseq.h:472 > #8 0x000055d08b1f7d94 in compareseq (xoff=, > xoff@entry=897, xlim=xlim@entry=17383882, yoff=yoff@entry=1353, ylim=ylim@entry=25500806, find_minimal=false, ctxt=ctxt@entry=0x7fff5bfa5610) > at ../lib/diffseq.h:510 looks like stack overflow? I guess the recursive nature of compareseq is got to cause this at some point? From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 20 09:22:59 2020 Received: (at 42931) by debbugs.gnu.org; 20 Aug 2020 13:22:59 +0000 Received: from localhost ([127.0.0.1]:41961 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8kWi-0006au-43 for submit@debbugs.gnu.org; Thu, 20 Aug 2020 09:22:59 -0400 Received: from quimby.gnus.org ([95.216.78.240]:57196) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8kWf-0006ag-Pa for 42931@debbugs.gnu.org; Thu, 20 Aug 2020 09:22:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=upjbJ+pRLDtwznTC/qz9+jRKH93Ho8welU4eoh9GJwY=; b=msG7AtcM5CQwqKFPUdQnw/+w/m cz6tqBZ4URXIYz7FLucEkAlJqG6MwAmI6Fw/YWAYbueAHfZZ7+P7CNbt8ie2gP0MFO7EehSuVIwQj 8W6+BaYtBlD//11Ap86l5R74xSTyOuFNDoGtsuTXMxxYFc5hLYzmQSjEfvXEBP1wKFr8=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k8kWW-0003of-LW; Thu, 20 Aug 2020 15:22:35 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#42931: 27.1; json-pretty-print-buffer on ~2MB line causes core dump References: <0b9da4d7-ca24-8e00-d49f-7630e42abe89@orcon.net.nz> <87364i2039.fsf@gnus.org> <831rk2eka9.fsf@gnu.org> X-Now-Playing: Various's _SHAPE Platform 2019_: "rkss - modern EDM tracks ni such styles as..." Date: Thu, 20 Aug 2020 15:22:31 +0200 In-Reply-To: <831rk2eka9.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 19 Aug 2020 18:18:38 +0300") Message-ID: <87imddwiy0.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > looks like stack overflow? I guess the recursive nature of compareseq > is got to cause this at some point? Yup. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 42931 Cc: psainty@orcon.net.nz, 42931@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > looks like stack overflow? I guess the recursive nature of compareseq > is got to cause this at some point? Yup. I'm not sure what to do about it, though. One easy way to "fix this" would be to not use replace-region-contents in json-pretty-print if the region is very large... but that's kinda just wallpapering over the problem. replace-region-contents itself could decide to not do all its fancy stuff if the region is very large, and just replace the contents in the normal way instead? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 20 09:26:26 2020 Received: (at 42931) by debbugs.gnu.org; 20 Aug 2020 13:26:26 +0000 Received: from localhost ([127.0.0.1]:41973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8kaI-0006gu-1h for submit@debbugs.gnu.org; Thu, 20 Aug 2020 09:26:26 -0400 Received: from mail-ot1-f50.google.com ([209.85.210.50]:43688) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8kaF-0006gh-I0 for 42931@debbugs.gnu.org; Thu, 20 Aug 2020 09:26:24 -0400 Received: by mail-ot1-f50.google.com with SMTP id r21so1413696ota.10 for <42931@debbugs.gnu.org>; Thu, 20 Aug 2020 06:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UDYKkKJGi8TFyAdUAClPCv0u9/rEPT1LEYkb9toyI0U=; b=U9sFYv+xDcNwG6W0q4NHNzww2X/ZXg44fz/WRFX0KJygOQ61DSdTM/EVBUuxdz6iNq QtUJ8HKxnEvuBU1nPbtIuCe0BqYcVcAmU2qsdqotf9Z9S41SiJOopKwjCFkfSOjrDkcW cyt0+nzwEMB/l+yfSJg5hJL5iLDe0caYrOAbb3SaghDYg5TJk/ZQRQv26ZcD6QeqGaZ8 8Wvjo7FgMY8ynMVsu0EqeBzYwDPqDQ+g0azHSG4ziqo4cTW+3QX7lYLv0qzknDlzmhrY CJkMo4cGfoG5O5fFpr0dAvt53N2VmyQ2BSVDvvgLBTM0bPCdFY7MtA6Iv4fcTISZmaYF lKyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UDYKkKJGi8TFyAdUAClPCv0u9/rEPT1LEYkb9toyI0U=; b=SX9tOCa/i0JM4fsu59+1FrM/dVjbPNNgdtggeYtSrJi9BqApm5BdKTwJ0+6Y5YfLec 3qteEc47ppAIfotq45AMS5mT87hflt9h+jUdYcuQhYhFfCw2JbHWvWIYves+DlfjOOQD PVzUbey3nRKPbOQdZfImyl2e00Y5AicLMW0R66teDqAwVgDX1tK7kQAj8pbksn33mwHw bxsWf1vCmm/4x4X8oPO9ao0+QuR31EYnE2dPttxEdq6+cTiTPdhPEwefnbEzAfHA+rxt kdIp9/JAXQNWSDLfq/h+nuZtrz6VB+cc4XIneQjLm61h7UiXc4hGNlfRnwy5toAoUs8T BWvw== X-Gm-Message-State: AOAM533ixCw7k73pHicAEVsl0rcKvDX3LGwocvvcI/FpKFN3GKLezMn2 axVxM+4hHVVDCOnGI+XKPA+pvH4m/+pvH8WqI98= X-Google-Smtp-Source: ABdhPJwezyqrJiAu9S3scVGDf2rJfINgattsVrHiqOu57eirHIm1/Trp0uUZd+YUiaG1CTK6SbxcyvDchB2WwPTIfQ4= X-Received: by 2002:a9d:20c1:: with SMTP id x59mr2106666ota.36.1597929977692; Thu, 20 Aug 2020 06:26:17 -0700 (PDT) MIME-Version: 1.0 References: <0b9da4d7-ca24-8e00-d49f-7630e42abe89@orcon.net.nz> <87364i2039.fsf@gnus.org> <831rk2eka9.fsf@gnu.org> <87imddwiy0.fsf@gnus.org> In-Reply-To: <87imddwiy0.fsf@gnus.org> From: Philipp Stephani Date: Thu, 20 Aug 2020 15:26:06 +0200 Message-ID: Subject: Re: bug#42931: 27.1; json-pretty-print-buffer on ~2MB line causes core dump To: Lars Ingebrigtsen Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 42931 Cc: Phil Sainty , 42931@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Am Do., 20. Aug. 2020 um 15:23 Uhr schrieb Lars Ingebrigtsen : > > Eli Zaretskii writes: > > > looks like stack overflow? I guess the recursive nature of compareseq > > is got to cause this at some point? > > Yup. > > I'm not sure what to do about it, though. One easy way to "fix this" > would be to not use replace-region-contents in json-pretty-print if the > region is very large... but that's kinda just wallpapering over the > problem. > > replace-region-contents itself could decide to not do all its fancy > stuff if the region is very large, and just replace the contents in the > normal way instead? I guess the underlying function (compareseq) should protect against unbounded recursion and fall back to a more coarse diff if necessary. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 20 09:39:50 2020 Received: (at 42931) by debbugs.gnu.org; 20 Aug 2020 13:39:50 +0000 Received: from localhost ([127.0.0.1]:41998 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8knG-0000mC-9s for submit@debbugs.gnu.org; Thu, 20 Aug 2020 09:39:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57804) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k8kn6-0000lp-Tk for 42931@debbugs.gnu.org; Thu, 20 Aug 2020 09:39:49 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41077) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k8kn0-00033l-QD; Thu, 20 Aug 2020 09:39:34 -0400 Received: from [176.228.60.248] (port=2312 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k8kn0-0000DI-9W; Thu, 20 Aug 2020 09:39:34 -0400 Date: Thu, 20 Aug 2020 16:39:26 +0300 Message-Id: <83d03lcu7l.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87imddwiy0.fsf@gnus.org> (message from Lars Ingebrigtsen on Thu, 20 Aug 2020 15:22:31 +0200) Subject: Re: bug#42931: 27.1; json-pretty-print-buffer on ~2MB line causes core dump References: <0b9da4d7-ca24-8e00-d49f-7630e42abe89@orcon.net.nz> <87364i2039.fsf@gnus.org> <831rk2eka9.fsf@gnu.org> <87imddwiy0.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 42931 Cc: psainty@orcon.net.nz, 42931@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: psainty@orcon.net.nz, 42931@debbugs.gnu.org > Date: Thu, 20 Aug 2020 15:22:31 +0200 > > Eli Zaretskii writes: > > > looks like stack overflow? I guess the recursive nature of compareseq > > is got to cause this at some point? > > Yup. > > I'm not sure what to do about it, though. One easy way to "fix this" > would be to not use replace-region-contents in json-pretty-print if the > region is very large... but that's kinda just wallpapering over the > problem. > > replace-region-contents itself could decide to not do all its fancy > stuff if the region is very large, and just replace the contents in the > normal way instead? compareseq is a Gnulib module, so maybe its implementation could be fixed to bail out when the recursion becomes too deep? From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 24 19:46:10 2020 Received: (at 42931) by debbugs.gnu.org; 24 Aug 2020 23:46:10 +0000 Received: from localhost ([127.0.0.1]:59582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kAMAE-0005y5-0X for submit@debbugs.gnu.org; Mon, 24 Aug 2020 19:46:10 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:40938) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kAMAC-0005xr-1C for 42931@debbugs.gnu.org; Mon, 24 Aug 2020 19:46:09 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 831821600E2; Mon, 24 Aug 2020 16:46:02 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id MVuUibuO4aHK; Mon, 24 Aug 2020 16:46:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8D0071600FD; Mon, 24 Aug 2020 16:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GXnl2XN6ZgUZ; Mon, 24 Aug 2020 16:46:01 -0700 (PDT) Received: from [192.168.1.9] (cpe-75-82-69-226.socal.res.rr.com [75.82.69.226]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 5577D1600E2; Mon, 24 Aug 2020 16:46:01 -0700 (PDT) To: Phil Sainty From: Paul Eggert Subject: Re: bug#42931: 27.1; json-pretty-print-buffer on ~2MB line causes core dump Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <14e2aff5-20e3-03a3-50ae-cfabee5bc406@cs.ucla.edu> Date: Mon, 24 Aug 2020 16:46:01 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 42931 Cc: 42931@debbugs.gnu.org, Philipp Stephani , Lars Ingebrigtsen , Bruno Haible , Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) The patch I installed into Emacs master for Bug#43016 also fixes Bug#42931's test case, at least for me. However, Bug#42931 prompted me to change the way that the Gnulib diffseq module recurses so that the stack size is O(log N) rather than O(N). I installed this change into Gnulib, here: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=7aadb23803a8fb71d07e6e87ffb1ca510d86f8ef and propagated this into Emacs master, here: https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=d494f9e81a6d11dcf6c22333cd950989b2051dff I doubt whether this patch needs to be backported into the emacs-27 branch. In theory even O(log N) might not be good enough if Emacs has a tiny stack and a huge buffer, but I doubt whether this is of practical concern. I'll cc this to Bruno Haible to give him a heads-up, since he created the diffseq module. Bruno, the bug report is here: https://bugs.gnu.org/42931 From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 25 02:13:26 2020 Received: (at 42931) by debbugs.gnu.org; 25 Aug 2020 06:13:26 +0000 Received: from localhost ([127.0.0.1]:60076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kASD0-0003Dz-Gq for submit@debbugs.gnu.org; Tue, 25 Aug 2020 02:13:26 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53194) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kASCw-0003Dk-7g for 42931@debbugs.gnu.org; Tue, 25 Aug 2020 02:13:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33173) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kASCq-0001oA-CF; Tue, 25 Aug 2020 02:13:16 -0400 Received: from [176.228.60.248] (port=2963 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kASCp-0002X2-Ky; Tue, 25 Aug 2020 02:13:16 -0400 Date: Tue, 25 Aug 2020 09:12:58 +0300 Message-Id: <83k0xn5k45.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <14e2aff5-20e3-03a3-50ae-cfabee5bc406@cs.ucla.edu> (message from Paul Eggert on Mon, 24 Aug 2020 16:46:01 -0700) Subject: Re: bug#42931: 27.1; json-pretty-print-buffer on ~2MB line causes core dump References: <14e2aff5-20e3-03a3-50ae-cfabee5bc406@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 42931 Cc: 42931@debbugs.gnu.org, larsi@gnus.org, bruno@clisp.org, p.stephani2@gmail.com, psainty@rcon.net.nz X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 42931@debbugs.gnu.org, Lars Ingebrigtsen , > Eli Zaretskii , Philipp Stephani , > Bruno Haible > From: Paul Eggert > Date: Mon, 24 Aug 2020 16:46:01 -0700 > > In theory even O(log N) might not be good enough if Emacs has a tiny stack and a > huge buffer, but I doubt whether this is of practical concern. What about "normal" Emacs builds? They usually have between 2MB and 8MB of stack. Should we worry about stack overflow in these cases? Maybe it is worth to add a stack-overflow protection to diffseq.h anyway? Almost anything is better than a segfault. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 25 14:19:13 2020 Received: (at 42931-done) by debbugs.gnu.org; 25 Aug 2020 18:19:13 +0000 Received: from localhost ([127.0.0.1]:36037 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kAdXM-0003nR-Uh for submit@debbugs.gnu.org; Tue, 25 Aug 2020 14:19:13 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:48164) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kAdXL-0003nF-2b for 42931-done@debbugs.gnu.org; Tue, 25 Aug 2020 14:19:11 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9E9991600C3; Tue, 25 Aug 2020 11:19:05 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 1foEO49fJUOn; Tue, 25 Aug 2020 11:19:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E2162160101; Tue, 25 Aug 2020 11:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FXRKUys9DQAH; Tue, 25 Aug 2020 11:19:04 -0700 (PDT) Received: from [192.168.1.9] (cpe-75-82-69-226.socal.res.rr.com [75.82.69.226]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id AA1FF1600C3; Tue, 25 Aug 2020 11:19:04 -0700 (PDT) Subject: Re: bug#42931: 27.1; json-pretty-print-buffer on ~2MB line causes core dump To: Eli Zaretskii References: <14e2aff5-20e3-03a3-50ae-cfabee5bc406@cs.ucla.edu> <83k0xn5k45.fsf@gnu.org> From: Paul Eggert Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkV5QWNtUUJFQURB QXlIMnhvVHU3cHBHNUQzYThGTVpFb243NGRDdmM0K3ExWEEySjJ0QnkycHdhVHFmCmhweHhk R0E5Smo1MFVKM1BENGJTVUVnTjh0TFowc2FuNDdsNVhUQUZMaTI0NTZjaVNsNW04c0thSGxH ZHQ5WG0KQUF0bVhxZVpWSVlYL1VGUzk2ZkR6ZjR4aEVtbS95N0xiWUVQUWRVZHh1NDd4QTVL aFRZcDVibHRGM1dZRHoxWQpnZDdneDA3QXV3cDdpdzdlTnZub0RUQWxLQWw4S1lEWnpiRE5D UUdFYnBZM2VmWkl2UGRlSStGV1FONFcra2doCnkrUDZhdTZQcklJaFlyYWV1YTdYRGRiMkxT MWVuM1NzbUUzUWpxZlJxSS9BMnVlOEpNd3N2WGUvV0szOEV6czYKeDc0aVRhcUkzQUZINmls QWhEcXBNbmQvbXNTRVNORnQ3NkRpTzFaS1FNcjlhbVZQa25qZlBtSklTcWRoZ0IxRApsRWR3 MzRzUk9mNlY4bVp3MHhmcVQ2UEtFNDZMY0ZlZnpzMGtiZzRHT1JmOHZqRzJTZjF0azVlVThN Qml5Ti9iClowM2JLTmpOWU1wT0REUVF3dVA4NGtZTGtYMndCeHhNQWhCeHdiRFZadWR6eERa SjFDMlZYdWpDT0pWeHEya2wKakJNOUVUWXVVR3FkNzVBVzJMWHJMdzYrTXVJc0hGQVlBZ1Jy NytLY3dEZ0JBZndoUEJZWDM0blNTaUhsbUxDKwpLYUhMZUNMRjVaSTJ2S20zSEVlQ1R0bE9n N3haRU9OZ3d6TCtmZEtvK0Q2U29DOFJSeEpLczhhM3NWZkk0dDZDCm5yUXp2SmJCbjZneGRn Q3U1aTI5SjFRQ1lyQ1l2cWwyVXlGUEFLK2RvOTkvMWpPWFQ0bTI4MzZqMXdBUkFRQUIKdENC UVlYVnNJRVZuWjJWeWRDQThaV2RuWlhKMFFHTnpMblZqYkdFdVpXUjFQb2tDUGdRVEFRSUFL QVVDVElCeQpaQUliQXdVSkVzd0RBQVlMQ1FnSEF3SUdGUWdDQ1FvTEJCWUNBd0VDSGdFQ0Y0 QUFDZ2tRN1pmcERtS3FmalJSCkd3LytJajAzZGhZZllsL2dYVlJpdXpWMWdHcmJIayt0bmZy SS9DN2ZBZW9GelE1dFZnVmluU2hhUGtabzBIVFAKZjE4eDZJREVkQWlPOE1xbzF5cDBDdEht ekdNQ0o1MG80R3JnZmpscjZnLyt2dEVPS2JobGVzek4yWHBKdnB3TQoyUWdHdm4vbGFUTFV1 OFBIOWFSV1RzN3FKSlpLS0tBYjRzeFljOTJGZWhQdTZGT0QwZERpeWhsREFxNGxPVjJtCmRC cHpRYmlvam9aelFMTVF3anBnQ1RLMjU3MmVLOUVPRVF5U1VUaFhyU0l6NkFTZW5wNE5ZVEZI czl0dUpRdlgKazlnWkRkUFNsM2JwKzQ3ZEd4bHhFV0xwQklNN3pJT053NGtzNGF6Z1Q4bnZE WnhBNUlaSHR2cUJsSkxCT2JZWQowTGU2MVdwMHkzVGxCRGgycWRLOGVZTDQyNlc0c2NFTVN1 aWc1Z2I4T0F0UWlCVzZrMnNHVXh4ZWl2OG92V3U4CllBWmdLSmZ1b1dJK3VSbk1FZGRydVk4 SnNvTTU0S2FLdlppa2tLczJiZzFuZHRMVnpIcEo2cUZaQzdRVmplSFUKaDYvQm1ndmRqV1Ba WUZUdE4rS0E5Q1dYM0dRS0tnTjN1dTk4OHl6bkQ3TG5COThUNEVVSDFIQS9HbmZCcU1WMQpn cHpUdlBjNHFWUWluQ21Ja0VGcDgzemwrRzVmQ2pKSjNXN2l2ekNuWW80S2hLTHBGVW05N29r VEtSMkxXM3haCnpFVzRjTFNXTzM4N01USzNDekRPeDVxZTZzNGE5MVp1Wk0vai9UUWRUTERh cU5uODNrQTRIcTQ4VUhYWXhjSWgKK05kOGsvM3c2bEZ1b0swd3JPRml5d2pMeCswdXI1am1t YmVjQkdIYzF4ZGhBRkc1QWcwRVRJQnlaQUVRQUthRgo2NzhUOXd5SDR3alRyVjFQejNjREVv U25WLzBaVXJPVDM3cDFkY0d5ai9JWHExeDY3MEhSVmFoQW1rMHNacFljCjI1UEY5RDVHUFlI RldsTmp1UFU5NnJEbmRYQjNoZWRtQlJoTGRDNGJBWGpJNERWK2JtZFZlK3EvSU1ubFpSYVYK bG05RWlNQ1ZBUjZ3MTNzUmV1N3FYa1c5cjNSd1kyQXpYc2twL3RBZTRCUktyMVptYnZpMm5i blE2ZXBFQzQycgpSYngwQjFFaGpiSVFaNUpIR2syNGlQVDdMZEJnbk5tb3M1d1lqendObGtN UUQ1VDBZZHpoazdKK1V4d0E1bTQ2Cm1PaFJEQzJyRlYvQTBnbTVUTHk4RFhqdi9Fc2M0Z1lu WWFpNlNRcW5VRVZoNUx1VjhZQ0pCbmlqcytUaXc3MXgKMWljbW42eEdJNDVFdWdKT2dlYyty THlwWWdwVnA0eDBISTVUODhxQlJZQ2t4SDNLZzhRbytFV05BOUE0TFJROQpEWDhuam9uYTBn ZjBzMDN0b2NLOGtCTjY2VW9xcVB0SEJuYzRlTWdCeW1DZmxLMTJlS2ZkMllZeG55ZzljWmF6 CldBNVZzbHZUeHBtNzZoYmc1b2lBRUgvVmcvOE14SHlBblBoZnJnd3lQcm1KRWNWQmFmZHNw Sm5ZUXhCWU5jbzIKTEZQSWhsT3ZXaDhyNGF0K3MrTTNMYjI2b1VUY3psZ2RXMVNmM1NEQTc3 Qk1SbkYwRlF5RSs3QXpWNzlNQk40eQpraXFhZXpReHRhRjFGeS90dmtoZmZTbzh1K2R3RzBF Z0poK3RlMzhnVGNJU1ZyMEdJUHBsTHo2WWhqcmJIclBSCkYxQ041VXVMOURCR2p4dU4zNVJM TlZFZnRhNlJVRmxSNk5jdFRqdnJBQkVCQUFHSkFpVUVHQUVDQUE4RkFreUEKY21RQ0d3d0ZD UkxNQXdBQUNna1E3WmZwRG1LcWZqU3JIQS8rS3pBS3ZUeFJoQTlNV05MeEl5SjdTNXVKMTZn cwpUM29DalpyQktHRWhLTU9HWDRPMEdBNlZPRXJ5TzdRUkNDWWFoM294U0czOElBbk5laXdK WGdVOUJ6a2s4NVVHCmJQRWQ3SEdGL1ZTZUhDUXdXb3U2anFVRFRTRHZuOVloTlRkRzBLWFBN NzRhQyt4cjJab3cxTzJtaFhpaGdXS0QKMER3KzBMWVBuVU9zUTBLT0Z4SFhYWUhtUnJTMU9a UFU1OUJMdmMrVFJoSWhhZlNIS0x3YlhLKzZja2t4Qng2aAo4ejVjY3BHMFFzNGJGaGRGWW5G ckVpZURMb0dtbkUyWUxoZFY2c3dKOVZOQ1M2cExpRW9oVDNmbTdhWG0xNXRaCk9JeXpNWmhI UlNBUGJsWHhRMFpTV2pxOG9ScmNZTkZ4YzRXMVVScEFrQkNPWUpvWHZRZkQ1TDNscUFsOFRD cUQKVXpZeGhIL3RKaGJEZEhycUhINzY3amFEYVRCMStUYWxwLzJBTUt3Y1hOT2Rpa2xHeGJt SFZHNllHbDZnOExyYgpzdTlOWkVJNHlMbEh6dWlrdGhKV2d6KzN2WmhWR3lObHQrSE5Jb0Y2 Q2pETDJvbXU1Y0VxNFJESE00NFFxUGs2Cmw3TzBwVXZOMW1UNEIrUzFiMDhSS3BxbS9mZjAx NUUzN0hOVi9waUl2Smx4R0FZejhQU2Z1R0NCMXRoTVlxbG0KZ2RoZDkvQmFiR0ZiR0dZSEE2 VTQvVDV6cVUrZjZ4SHkxU3NBUVoxTVNLbEx3ZWtCSVQrNC9jTFJHcUNIam5WMApxNUgvVDZh N3Q1bVBrYnpTck9MU280cHVqK0lUb05qWXlZSURCV3pobEExOWF2T2ErcnZVam1IdEQzc0ZO N2NYCld0a0dvaThidU5jYnk0VT0KPUFMNm8KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo= Organization: UCLA Computer Science Department Message-ID: <6e7b8005-3865-50d1-be6a-5673fc6dc5c9@cs.ucla.edu> 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 MIME-Version: 1.0 In-Reply-To: <83k0xn5k45.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 (----) X-Debbugs-Envelope-To: 42931-done Cc: 42931-done@debbugs.gnu.org, larsi@gnus.org, bruno@clisp.org, p.stephani2@gmail.com, psainty@rcon.net.nz X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.9 (-----) 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. From unknown Wed Jun 18 23:10:38 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 23 Sep 2020 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator