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

Previous Next

Full log

Message #11 received at 42931 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: psainty <at> orcon.net.nz, 42931 <at> debbugs.gnu.org
Subject: Re: bug#42931: 27.1;
 json-pretty-print-buffer on ~2MB line causes core dump
Date: Wed, 19 Aug 2020 18:18:38 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Wed, 19 Aug 2020 16:15:38 +0200
> Cc: 42931 <at> debbugs.gnu.org
> 
> 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

looks like stack overflow?  I guess the recursive nature of compareseq
is got to cause this at some point?

Previous Next

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