GNU bug report logs - #27779
26.0.50: read -- Re-entering top level after C stack overflow

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Keith David Bershatsky <esq <at> lawlist.com>
Subject: bug#27779: closed (Re: bug#27779: 26.0.50: read -- Re-entering
 top level after C stack overflow)
Date: Fri, 22 Apr 2022 00:27:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#27779: 26.0.50:  read -- Re-entering top level after C stack overflow

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 27779 <at> debbugs.gnu.org.

-- 
27779: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27779
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Keith David Bershatsky <esq <at> lawlist.com>
Cc: 27779-done <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 npostavs <at> gmail.com, mail <at> vasilij.de
Subject: Re: bug#27779: 26.0.50: read -- Re-entering top level after C stack
 overflow
Date: Thu, 21 Apr 2022 17:26:05 -0700

On 4/21/22 11:56, Keith David Bershatsky wrote:
> As to the most recent versions of Emacs 28 and the Master Branch, built on El Capitan, the issue is not present when using the test case:

Thanks for checking. I think this bug was addressed in 2018, here:

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=b38b91a83491b6812e8267d0247355f0e8e3e189

so I am closing the bug report.

[Message part 3 (message/rfc822, inline)]

From: Keith David Bershatsky <esq <at> lawlist.com>
To: Emacs Bug Reports <bug-gnu-emacs <at> gnu.org>
Subject: 26.0.50:  read -- Re-entering top level after C stack overflow
Date: Thu, 20 Jul 2017 19:12:07 -0700

I have modified versions of undo-tree.el and the cl family of functions (with different names [e.g., "lcl-..."] that use the old-style defstruct), which may be able to still take advantage of the vector method of dealing with structs.  I am receiving a message "Re-entering top level after C stack overflow".  It appears that `read` can no longer handle the following type of structure, perhaps because there is no built-in backwards compatibility -- this is a small example of the what `read` is able to handle in earlier versions of Emacs, but not the current master branch:

[cl-struct-undo-tree [nil ([nil ([nil ([nil ([nil ([nil ([nil ([nil ([nil ([nil ([nil ([nil ([nil ([nil ([nil ([nil ([nil ([nil ([nil ([nil ([nil ([nil ([nil ([nil ([nil ([nil (#1=[nil nil ((26 . 27)) nil (22874 59645 117315 0) 0 nil (((22874 59645 117309 0) . t)) nil nil]) ((25 . 26)) nil (22874 59645 117331 0) 0 nil (((22874 59645 107309 0))) nil nil]) ((24 . 25)) nil (22874 59645 117335 0) 0 nil (((22874 59645 97309 0))) nil nil]) ((23 . 24)) nil (22874 59645 117339 0) 0 nil (((22874 59645 87309 0))) nil nil]) ((22 . 23)) nil (22874 59645 117343 0) 0 nil (((22874 59645 77309 0))) nil nil]) ((21 . 22)) nil (22874 59645 117347 0) 0 nil (((22874 59645 67309 0))) nil nil]) ((20 . 21)) nil (22874 59645 117351 0) 0 nil (((22874 59645 57309 0))) nil nil]) ((19 . 20)) nil (22874 59645 117354 0) 0 nil (((22874 59645 47309 0))) nil nil]) ((18 . 19)) nil (22874 59645 117358 0) 0 nil (((22874 59645 37309 0))) nil nil]) ((17 . 18)) nil (22874 59645 117363 0) 0 nil (((22874 59645 27309 0))) nil
  nil]) ((16 . 17)) nil (22874 59645 117366 0) 0 nil (((22874 59645 17309 0))) nil nil]) ((15 . 16)) nil (22874 59645 117370 0) 0 nil (((22874 59645 7309 0))) nil nil]) ((14 . 15)) nil (22874 59645 117374 0) 0 nil (((22874 59644 997309 0))) nil nil]) ((13 . 14)) nil (22874 59645 117378 0) 0 nil (((22874 59644 987309 0))) nil nil]) ((12 . 13)) nil (22874 59645 117382 0) 0 nil (((22874 59644 977309 0))) nil nil]) ((11 . 12)) nil (22874 59645 117386 0) 0 nil (((22874 59644 967309 0))) nil nil]) ((10 . 11)) nil (22874 59645 117390 0) 0 nil (((22874 59644 957309 0))) nil nil]) ((9 . 10)) nil (22874 59645 117394 0) 0 nil (((22874 59644 947309 0))) nil nil]) ((8 . 9)) nil (22874 59645 117398 0) 0 nil (((22874 59644 937309 0))) nil nil]) ((7 . 8)) nil (22874 59645 117402 0) 0 nil (((22874 59644 927309 0))) nil nil]) ((6 . 7)) nil (22874 59645 117405 0) 0 nil (((22874 59644 917309 0))) nil nil]) ((5 . 6)) nil (22874 59645 117409 0) 0 nil (((22874 59644 907309 0))) nil nil]) ((4 . 5)) nil (228
 74 59645 117413 0) 0 nil (((22874 59644 897309 0))) nil nil]) ((3 . 4)) nil (22874 59645 117417 0) 0 nil (((22874 59644 887309 0))) nil nil]) ((2 . 3)) nil (22874 59645 117420 0) 0 nil (((22874 59644 877309 0))) nil nil]) ((1 . 2) (t 22874 59561 0 0)) nil (22874 59645 117425 0) 0 nil (((22874 59644 867309 0))) nil nil]) nil nil (22874 59632 379899 0) 0 nil (((0 0))) nil nil] #1# 216 26 nil #1#]

Here is the backtrace for the first 20 frames:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff5f26ef08
0x000000010023ae38 in read1 (readcharfun=Cannot access memory at address 0x7fff5f26ef08
) at lread.c:2674
2674	{
(gdb) bt
#0  0x000000010023ae38 in read1 (readcharfun=Cannot access memory at address 0x7fff5f26ef08
) at lread.c:2674
#1  0x000000010023eba5 in read_list (flag=true, readcharfun={i = 4773552677}) at lread.c:3866
#2  0x000000010023e7d6 in read_vector (readcharfun={i = 4773552677}, bytecodeflag=false) at lread.c:3776
#3  0x000000010023b01e in read1 (readcharfun={i = 4773552677}, pch=0x7fff5f2777a4, first_in_list=true) at lread.c:2695
#4  0x000000010023eba5 in read_list (flag=false, readcharfun={i = 4773552677}) at lread.c:3866
#5  0x000000010023b001 in read1 (readcharfun={i = 4773552677}, pch=0x7fff5f27bc24, first_in_list=false) at lread.c:2692
#6  0x000000010023eba5 in read_list (flag=true, readcharfun={i = 4773552677}) at lread.c:3866
#7  0x000000010023e7d6 in read_vector (readcharfun={i = 4773552677}, bytecodeflag=false) at lread.c:3776
#8  0x000000010023b01e in read1 (readcharfun={i = 4773552677}, pch=0x7fff5f280134, first_in_list=true) at lread.c:2695
#9  0x000000010023eba5 in read_list (flag=false, readcharfun={i = 4773552677}) at lread.c:3866
#10 0x000000010023b001 in read1 (readcharfun={i = 4773552677}, pch=0x7fff5f2845b4, first_in_list=false) at lread.c:2692
#11 0x000000010023eba5 in read_list (flag=true, readcharfun={i = 4773552677}) at lread.c:3866
#12 0x000000010023e7d6 in read_vector (readcharfun={i = 4773552677}, bytecodeflag=false) at lread.c:3776
#13 0x000000010023b01e in read1 (readcharfun={i = 4773552677}, pch=0x7fff5f288ac4, first_in_list=true) at lread.c:2695
#14 0x000000010023eba5 in read_list (flag=false, readcharfun={i = 4773552677}) at lread.c:3866
#15 0x000000010023b001 in read1 (readcharfun={i = 4773552677}, pch=0x7fff5f28cf44, first_in_list=false) at lread.c:2692
#16 0x000000010023eba5 in read_list (flag=true, readcharfun={i = 4773552677}) at lread.c:3866
#17 0x000000010023e7d6 in read_vector (readcharfun={i = 4773552677}, bytecodeflag=false) at lread.c:3776
#18 0x000000010023b01e in read1 (readcharfun={i = 4773552677}, pch=0x7fff5f291454, first_in_list=true) at lread.c:2695
#19 0x000000010023eba5 in read_list (flag=false, readcharfun={i = 4773552677}) at lread.c:3866
#20 0x000000010023b001 in read1 (readcharfun={i = 4773552677}, pch=0x7fff5f2958d4, first_in_list=false) at lread.c:2692

***

Previous Next

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