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

[Lars Ingebrigtsen]

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