From: Lars Ingebrigtsen <larsi@gnus.org>
To: Phil Sainty <psainty@orcon.net.nz>
Cc: 42931@debbugs.gnu.org
Subject: bug#42931: 27.1; json-pretty-print-buffer on ~2MB line causes core dump
Date: Wed, 19 Aug 2020 16:15:38 +0200 [thread overview]
Message-ID: <87364i2039.fsf@gnus.org> (raw)
In-Reply-To: <0b9da4d7-ca24-8e00-d49f-7630e42abe89@orcon.net.nz> (Phil Sainty's message of "Thu, 20 Aug 2020 01:50:55 +1200")
Phil Sainty <psainty@orcon.net.nz> 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=<optimized out>) 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 <handle_fatal_signal>)
at sysdep.c:1760
#4 0x000055d08b19c019 in deliver_fatal_thread_signal (sig=11) at sysdep.c:1883
#5 handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>)
at sysdep.c:1883
#6 0x00007fbbb530d140 in <signal handler called> ()
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=<optimized out>,
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=<optimized out>,
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=<optimized out>,
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=<optimized out>,
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=<optimized out>,
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=<optimized out>, 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=<optimized out>, 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=<optimized out>, 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=<optimized out>, max_costs=<optimized out>) 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=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) 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=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) 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=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) 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
next prev parent reply other threads:[~2020-08-19 14:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-19 13:50 bug#42931: 27.1; json-pretty-print-buffer on ~2MB line causes core dump Phil Sainty
2020-08-19 14:15 ` Lars Ingebrigtsen [this message]
2020-08-19 15:18 ` Eli Zaretskii
2020-08-20 13:22 ` Lars Ingebrigtsen
2020-08-20 13:26 ` Philipp Stephani
2020-08-20 13:39 ` Eli Zaretskii
2020-08-24 23:46 ` Paul Eggert
2020-08-25 6:12 ` Eli Zaretskii
2020-08-25 18:19 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87364i2039.fsf@gnus.org \
--to=larsi@gnus.org \
--cc=42931@debbugs.gnu.org \
--cc=psainty@orcon.net.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).