--- Begin Message ---
|
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
***
--- End Message ---
--- Begin Message ---
|
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 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 |
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.
--- End Message ---