GNU bug report logs - #42931
27.1; json-pretty-print-buffer on ~2MB line causes core dump

Previous Next

Package: emacs;

Reported by: Phil Sainty <psainty <at> orcon.net.nz>

Date: Wed, 19 Aug 2020 13:52:02 UTC

Severity: normal

Found in version 27.1

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log

View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 42931 <at> 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

Phil Sainty <psainty <at> 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 <at> entry=11, backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:408
#2  0x000055d08b0a0f5f in handle_fatal_signal (sig=sig <at> entry=11)
    at sysdep.c:1786
#3  0x000055d08b19bf9d in deliver_thread_signal
    (sig=sig <at> 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 <at> entry=897, xlim=xlim <at> entry=17383858, yoff=yoff <at> entry=1353, ylim=ylim <at> entry=25500750, find_minimal=false, ctxt=ctxt <at> entry=0x7fff5bfa5610)
    at ../lib/diffseq.h:472
#8  0x000055d08b1f7d94 in compareseq (xoff=<optimized out>, 
    xoff <at> entry=897, xlim=xlim <at> entry=17383882, yoff=yoff <at> entry=1353, ylim=ylim <at> entry=25500806, find_minimal=false, ctxt=ctxt <at> entry=0x7fff5bfa5610)
    at ../lib/diffseq.h:510
#9  0x000055d08b1f7d94 in compareseq (xoff=<optimized out>, 
    xoff <at> entry=897, xlim=xlim <at> entry=17383917, yoff=yoff <at> entry=1353, ylim=ylim <at> en
try=25500849, find_minimal=false, ctxt=ctxt <at> entry=0x7fff5bfa5610)
    at ../lib/diffseq.h:510
#10 0x000055d08b1f7d94 in compareseq (xoff=<optimized out>, 
    xoff <at> entry=897, xlim=xlim <at> entry=17383963, yoff=yoff <at> entry=1353, ylim=ylim <at> entry=25500881, find_minimal=false, ctxt=ctxt <at> entry=0x7fff5bfa5610)
    at ../lib/diffseq.h:510
#11 0x000055d08b1f7d94 in compareseq (xoff=<optimized out>, 
    xoff <at> entry=897, xlim=xlim <at> entry=17384016, yoff=yoff <at> entry=1353, ylim=ylim <at> entry=25500898, find_minimal=false, ctxt=ctxt <at> entry=0x7fff5bfa5610)
    at ../lib/diffseq.h:510
#12 0x000055d08b1f7d94 in compareseq (xoff=<optimized out>, 
    xoff <at> entry=897, xlim=xlim <at> entry=17384024, yoff=yoff <at> entry=1353, ylim=ylim <at> entry=25500964, find_minimal=false, ctxt=ctxt <at> 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 <at> entry=146, xlim=xlim <at> entry=18922266, yoff=yoff <at> entry=186, ylim=ylim <at> entry=27160236, find_minimal=false, ctxt=ctxt <at> entry=0x7fff5bfa5610) at ../lib/diffseq.h:512
#36799 0x000055d08b1f7d94 in compareseq (xoff=<optimized out>, xoff <at> entry=146, xlim=xlim <at> entry=18922364, yoff=yoff <at> entry=186, ylim=ylim <at> entry=27160398, find_minimal=find_minimal <at> entry=false, ctxt=ctxt <at> entry=0x7fff5bfa5610) at ../lib/diffseq.h:510
#36800 0x000055d08b1f7db9 in compareseq (xoff=<optimized out>, xoff <at> entry=0, xlim=18922364, xlim <at> entry=18922365, yoff=1, yoff <at> entry=0, ylim=27160398, ylim <at> entry=27160399, find_minimal=find_minimal <at> entry=false, ctxt=ctxt <at> 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 <at> 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 <at> 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 <at> 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 <at> entry=2, args=args <at> 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 <at> entry=3, args=args <at> 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
This bug report was last modified 4 years and 267 days ago.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.