* bug#22120: 25.1.50; segfault while running circe
@ 2015-12-08 20:19 Eric Hanchrow
2015-12-08 20:33 ` Eli Zaretskii
` (3 more replies)
0 siblings, 4 replies; 24+ messages in thread
From: Eric Hanchrow @ 2015-12-08 20:19 UTC (permalink / raw)
To: 22120
[-- Attachment #1.1: Type: text/plain, Size: 2474 bytes --]
I don't remember exactly what I did, but (since I'd seen this problem
before), I'd started emacs under gdb. I was using the circe IRC client
via M-x circe RET. I don't think I'd typed anything immediately before
emacs crashed.
In GNU Emacs 25.1.50.1 (x86_64-unknown-linux-gnu)
of 2015-12-07
Repository revision: 6148555ee5a3d0139ae517803718b3e0357933c7
Configured using:
'configure --enable-checking --enable-check-lisp-object-type
--config-cache 'CFLAGS=-Og -g3''
Configured features:
SOUND NOTIFY LIBSELINUX LIBXML2 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045
ietf-drums mm-util help-fns mail-prsvr mail-utils term/xterm xterm
byte-opt gv bytecomp byte-compile cl-extra help-mode easymenu
cl-loaddefs pcase cl-lib cconv time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type tabulated-list
newcomment elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow timer select mouse jit-lock font-lock syntax facemenu
font-core frame cl-generic cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
charscript case-table epa-hook jka-cmpr-hook help simple abbrev obarray
minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp
files text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote inotify multi-tty
make-network-process emacs)
Memory information:
((conses 16 120081 4220)
(symbols 48 27737 0)
(miscs 40 39 99)
(strings 32 31794 4135)
(string-bytes 1 568797)
(vectors 16 9778)
(vector-slots 8 383643 2601)
(floats 8 126 564)
(intervals 56 176 1)
(buffers 976 11)
(heap 1024 25898 831))
[-- Attachment #1.2: Type: text/html, Size: 3365 bytes --]
[-- Attachment #2: backtrace.log.gz --]
[-- Type: application/x-gzip, Size: 7554 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: 25.1.50; segfault while running circe
2015-12-08 20:19 bug#22120: 25.1.50; segfault while running circe Eric Hanchrow
@ 2015-12-08 20:33 ` Eli Zaretskii
2015-12-08 20:36 ` Eric Hanchrow
2015-12-08 20:36 ` John Wiegley
` (2 subsequent siblings)
3 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2015-12-08 20:33 UTC (permalink / raw)
To: Eric Hanchrow; +Cc: 22120
> From: Eric Hanchrow <eric.hanchrow@gmail.com>
> Date: Tue, 08 Dec 2015 20:19:11 +0000
>
> I don't remember exactly what I did, but (since I'd seen this problem
> before), I'd started emacs under gdb. I was using the circe IRC client
> via M-x circe RET. I don't think I'd typed anything immediately before
> emacs crashed.
>
> In GNU Emacs 25.1.50.1 (x86_64-unknown-linux-gnu)
> of 2015-12-07
Thanks. The master branch takes a back seat for now, so if you could
reproduce this problem on the emacs-25 branch, we will know it's
urgent.
Also, can you tell why XCAR segfaulted, exactly? What is the value of
'c' in frame 0?
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: 25.1.50; segfault while running circe
2015-12-08 20:19 bug#22120: 25.1.50; segfault while running circe Eric Hanchrow
2015-12-08 20:33 ` Eli Zaretskii
@ 2015-12-08 20:36 ` John Wiegley
2015-12-08 20:38 ` Eric Hanchrow
2015-12-10 18:42 ` bug#22120: Another backtrace Eric Hanchrow
2015-12-12 22:37 ` Eric Hanchrow
3 siblings, 1 reply; 24+ messages in thread
From: John Wiegley @ 2015-12-08 20:36 UTC (permalink / raw)
To: Eric Hanchrow; +Cc: 22120
>>>>> Eric Hanchrow <eric.hanchrow@gmail.com> writes:
> I don't remember exactly what I did, but (since I'd seen this problem
> before), I'd started emacs under gdb. I was using the circe IRC client via
> M-x circe RET. I don't think I'd typed anything immediately before emacs
> crashed.
Nice backtrace, thank you. I wonder what object XCAR is being applied to, that
it would segfault like this.
Does this happen consistently, even if you don't know exactly what caused it?
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: 25.1.50; segfault while running circe
2015-12-08 20:33 ` Eli Zaretskii
@ 2015-12-08 20:36 ` Eric Hanchrow
2015-12-08 20:54 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: Eric Hanchrow @ 2015-12-08 20:36 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22120
Dunno if I'm doing this right:
(gdb) down
#1 CAR (c=...) at lisp.h:1244
1244 return (CONSP (c) ? XCAR (c)
(gdb)
#0 XCAR (c=...) at lisp.h:1216
1216 return lisp_h_XCAR (c);
(gdb) p c
$4 = <optimized out>
(gdb) up
#1 CAR (c=...) at lisp.h:1244
1244 return (CONSP (c) ? XCAR (c)
(gdb) p c
$5 = <optimized out>
(gdb) up
#2 Fcar (list=...) at data.c:527
527 return CAR (list);
(gdb) p list
$6 = {
i = 7791354264813860195
}
(gdb) xpr list
Lisp_Cons
$7 = (struct Lisp_Cons *) 0x6c20736c69747560
Cannot access memory at address 0x6c20736c69747560
(gdb)
On Tue, Dec 8, 2015 at 12:33 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Eric Hanchrow <eric.hanchrow@gmail.com>
> > Date: Tue, 08 Dec 2015 20:19:11 +0000
> >
> > I don't remember exactly what I did, but (since I'd seen this problem
> > before), I'd started emacs under gdb. I was using the circe IRC client
> > via M-x circe RET. I don't think I'd typed anything immediately before
> > emacs crashed.
> >
> > In GNU Emacs 25.1.50.1 (x86_64-unknown-linux-gnu)
> > of 2015-12-07
>
> Thanks. The master branch takes a back seat for now, so if you could
> reproduce this problem on the emacs-25 branch, we will know it's
> urgent.
>
> Also, can you tell why XCAR segfaulted, exactly? What is the value of
> 'c' in frame 0?
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: 25.1.50; segfault while running circe
2015-12-08 20:36 ` John Wiegley
@ 2015-12-08 20:38 ` Eric Hanchrow
0 siblings, 0 replies; 24+ messages in thread
From: Eric Hanchrow @ 2015-12-08 20:38 UTC (permalink / raw)
To: John Wiegley; +Cc: 22120
[-- Attachment #1: Type: text/plain, Size: 406 bytes --]
On Tue, Dec 8, 2015 at 12:36 PM John Wiegley <jwiegley@gmail.com> wrote:
>
> Nice backtrace, thank you. I wonder what object XCAR is being applied to,
> that
> it would segfault like this.
>
Seems garbagy; see my earlier response to Eli.
>
> Does this happen consistently, even if you don't know exactly what caused
> it?
>
Nope, it seems quite random. I've probably seen it a total of 3 or 4
times.
[-- Attachment #2: Type: text/html, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: 25.1.50; segfault while running circe
2015-12-08 20:36 ` Eric Hanchrow
@ 2015-12-08 20:54 ` Eli Zaretskii
2015-12-08 21:03 ` John Wiegley
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2015-12-08 20:54 UTC (permalink / raw)
To: Eric Hanchrow; +Cc: 22120
> From: Eric Hanchrow <eric.hanchrow@gmail.com>
> Date: Tue, 8 Dec 2015 12:36:52 -0800
> Cc: 22120@debbugs.gnu.org
>
> Dunno if I'm doing this right:
You are, thanks.
> (gdb) down
> #1 CAR (c=...) at lisp.h:1244
> 1244 return (CONSP (c) ? XCAR (c)
> (gdb)
> #0 XCAR (c=...) at lisp.h:1216
> 1216 return lisp_h_XCAR (c);
> (gdb) p c
> $4 = <optimized out>
> (gdb) up
> #1 CAR (c=...) at lisp.h:1244
> 1244 return (CONSP (c) ? XCAR (c)
> (gdb) p c
> $5 = <optimized out>
> (gdb) up
> #2 Fcar (list=...) at data.c:527
> 527 return CAR (list);
> (gdb) p list
> $6 = {
> i = 7791354264813860195
> }
> (gdb) xpr list
> Lisp_Cons
> $7 = (struct Lisp_Cons *) 0x6c20736c69747560
> Cannot access memory at address 0x6c20736c69747560
That "address" is part of a string: "`utils l" (without the quotes).
So I'm guessing some code is overwriting the stack or writing beyond
the limits of a char array. The question is where?
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: 25.1.50; segfault while running circe
2015-12-08 20:54 ` Eli Zaretskii
@ 2015-12-08 21:03 ` John Wiegley
2015-12-09 15:29 ` Eric Hanchrow
0 siblings, 1 reply; 24+ messages in thread
From: John Wiegley @ 2015-12-08 21:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22120, Eric Hanchrow
>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>> $7 = (struct Lisp_Cons *) 0x6c20736c69747560
>> Cannot access memory at address 0x6c20736c69747560
> That "address" is part of a string: "`utils l" (without the quotes). So I'm
> guessing some code is overwriting the stack or writing beyond the limits of
> a char array. The question is where?
Nice catch! Forgot to look for that.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: 25.1.50; segfault while running circe
2015-12-08 21:03 ` John Wiegley
@ 2015-12-09 15:29 ` Eric Hanchrow
[not found] ` <83h9jrbl7b.fsf@gnu.org>
0 siblings, 1 reply; 24+ messages in thread
From: Eric Hanchrow @ 2015-12-09 15:29 UTC (permalink / raw)
To: John Wiegley, Eli Zaretskii; +Cc: 22120
[-- Attachment #1.1: Type: text/plain, Size: 672 bytes --]
Here's a similar crash from emacs 25.
On Tue, Dec 8, 2015 at 1:03 PM John Wiegley <jwiegley@gmail.com> wrote:
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> $7 = (struct Lisp_Cons *) 0x6c20736c69747560
> >> Cannot access memory at address 0x6c20736c69747560
>
> > That "address" is part of a string: "`utils l" (without the quotes). So
> I'm
> > guessing some code is overwriting the stack or writing beyond the limits
> of
> > a char array. The question is where?
>
> Nice catch! Forgot to look for that.
>
> --
> John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
> http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
>
[-- Attachment #1.2: Type: text/html, Size: 1168 bytes --]
[-- Attachment #2: backtrace.log --]
[-- Type: application/octet-stream, Size: 41108 bytes --]
#0 XFLOAT_DATA (f=...) at lisp.h:2503
No locals.
#1 Fabs (arg=...) at floatfns.c:283
No locals.
#2 0x0000000000581102 in eval_sub (form=...) at eval.c:2166
i = 1
maxargs = 1
args_left = {
i = 0
}
numargs = <optimized out>
val = <optimized out>
original_fun = <optimized out>
original_args = {
i = 28754355
}
count = 53
argvals = {{
i = -1
}, {
i = 53
}, {
i = 10
}, {
i = 53
}, {
i = 744974
}, {
i = 186243
}, {
i = 28754099
}, {
i = 2
}}
#3 0x0000000000580e85 in eval_sub (form=...) at eval.c:2131
vals = 0x7fffffffb210
argnum = 1
sa_avail = <optimized out>
sa_must_free = false
args_left = {
i = 28754339
}
numargs = <optimized out>
val = <optimized out>
original_fun = <optimized out>
original_args = {
i = 28754339
}
count = 52
argvals = {{
i = -1
}, {
i = 52
}, {
i = 31174227
}, {
i = 2
}, {
i = 1
}, {
i = 1
}, {
i = 28754083
}, {
i = 12455941
}}
#4 0x00000000005816b0 in Fand (args=...) at eval.c:361
val = <optimized out>
#5 0x0000000000580cdd in eval_sub (form=...) at eval.c:2119
args_left = {
i = 28754403
}
numargs = <optimized out>
val = <optimized out>
original_fun = {
i = 178432
}
original_args = {
i = 28754403
}
count = 51
argvals = {{
i = 76898675
}, {
i = 0
}, {
i = 6
}, {
i = 13024576
}, {
i = 4611686019484352512
}, {
i = 5681070
}, {
i = 23760
}, {
i = 5683216
}}
#6 0x0000000000584eac in Fif (args=...) at eval.c:380
cond = <optimized out>
#7 0x0000000000580cdd in eval_sub (form=...) at eval.c:2119
args_left = {
i = 28754291
}
numargs = <optimized out>
val = <optimized out>
original_fun = {
i = 22272
}
original_args = {
i = 28754291
}
count = 50
argvals = {{
i = 13024576
}, {
i = 32121872
}, {
i = 76894419
}, {
i = 5681029
}, {
i = 4611686019484352512
}, {
i = 4294967296
}, {
i = 4611686018628714496
}, {
i = 13024576
}}
#8 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#9 0x0000000000581ccf in funcall_lambda (fun=..., fun@entry=..., nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffffffb5b8)
at eval.c:2914
lexenv = {
i = 76894419
}
i = 1
optional = false
rest = false
#10 0x000000000058287c in Ffuncall (nargs=2, args=<optimized out>) at eval.c:2754
numargs = 1
val = <optimized out>
internal_args = <optimized out>
count = 48
#11 0x0000000000580f28 in eval_sub (form=...) at eval.c:2137
vals = 0x7fffffffb5b0
argnum = <optimized out>
sa_avail = <optimized out>
sa_must_free = false
args_left = {
i = 0
}
numargs = <optimized out>
val = <optimized out>
original_fun = <optimized out>
original_args = {
i = 28753667
}
count = 47
argvals = {{
i = 6
}, {
i = 47
}, {
i = -1
}, {
i = 5772737
}, {
i = 32880
}, {
i = 28756467
}, {
i = 4611686019484352512
}, {
i = 4611686018595160064
}}
#12 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#13 0x0000000000584ff4 in Fcond (args=...) at eval.c:408
clause = {
i = 28753699
}
val = <optimized out>
#14 0x0000000000580cdd in eval_sub (form=...) at eval.c:2119
args_left = {
i = 28747267
}
numargs = <optimized out>
val = <optimized out>
original_fun = {
i = 178480
}
original_args = {
i = 28747267
}
count = 46
argvals = {{
i = 13024576
}, {
i = 32121872
}, {
i = 76894499
}, {
i = 5681029
}, {
i = 23760
}, {
i = 4300650512
}, {
i = 14467536
}, {
i = 13024576
}}
#15 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#16 0x0000000000581ccf in funcall_lambda (fun=..., fun@entry=..., nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffffffb898)
at eval.c:2914
lexenv = {
i = 76894499
}
i = 1
optional = false
rest = false
#17 0x000000000058287c in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffb890) at eval.c:2754
numargs = 1
val = <optimized out>
internal_args = <optimized out>
count = 44
#18 0x0000000000582990 in call1 (fn=..., fn@entry=..., arg1=...) at eval.c:2552
No locals.
#19 0x000000000058f1e8 in mapcar1 (leni=leni@entry=2599, vals=vals@entry=0x5446e80, fn=fn@entry=..., seq=..., seq@entry=...) at fns.c:2522
dummy = <optimized out>
i = 2554
#20 0x000000000058f73f in Fmapcar (function=..., sequence=...) at fns.c:2587
len = {
i = 7
}
args = 0x5446e80
ret = <optimized out>
sa_avail = <optimized out>
sa_must_free = true
#21 0x0000000000581168 in eval_sub (form=...) at eval.c:2169
i = 2
maxargs = 2
args_left = {
i = 0
}
numargs = <optimized out>
val = <optimized out>
original_fun = <optimized out>
original_args = {
i = 28750547
}
count = 42
argvals = {{
i = 75722691
}, {
i = 72935811
}, {
i = 28778067
}, {
i = 5681029
}, {
i = 4611686019484352512
}, {
i = 4294967296
}, {
i = 28237776
}, {
i = 13024576
}}
#22 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#23 0x0000000000585ba1 in FletX (args=...) at eval.c:882
val = {
i = 75722691
}
lexenv = {
i = 75723107
}
#24 0x0000000000580cdd in eval_sub (form=...) at eval.c:2119
args_left = {
i = 28778067
}
numargs = <optimized out>
val = <optimized out>
original_fun = {
i = 25728
}
original_args = {
i = 28778067
}
count = 40
argvals = {{
i = 13024576
}, {
i = 32121872
}, {
i = 75723107
}, {
i = 5681029
}, {
i = 12455989
}, {
i = 4311726992
}, {
i = 744774
}, {
i = 13024576
}}
#25 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#26 0x0000000000581ccf in funcall_lambda (fun=..., fun@entry=..., nargs=nargs@entry=3, arg_vector=arg_vector@entry=0x7fffffffbba0)
at eval.c:2914
lexenv = {
i = 75723107
}
i = 3
optional = false
rest = false
#27 0x0000000000580823 in apply_lambda (fun=..., fun@entry=..., args=..., count=count@entry=38) at eval.c:2794
args_left = <optimized out>
i = 3
arg_vector = 0x7fffffffbba0
tem = {
i = 28758691
}
sa_avail = <optimized out>
sa_must_free = false
#28 0x0000000000581593 in eval_sub (form=...) at eval.c:2241
val = <optimized out>
original_fun = {
i = 16692944
}
original_args = {
i = 28758643
}
count = 38
argvals = {{
i = 140737488338224
}, {
i = 5773099
}, {
i = 12465885
}, {
i = 5772737
}, {
i = 73261283
}, {
i = 5768473
}, {
i = 0
}, {
i = 0
}}
#29 0x00000000005851bc in Fsetq (args=...) at eval.c:497
args_left = {
i = 28758563
}
val = {
i = 28758563
}
lex_binding = <optimized out>
#30 0x0000000000580cdd in eval_sub (form=...) at eval.c:2119
args_left = {
i = 28758563
}
numargs = <optimized out>
val = <optimized out>
original_fun = {
i = 36336
}
original_args = {
i = 28758563
}
count = 37
argvals = {{
i = 12465741
}, {
i = 5801692
}, {
i = 72935811
}, {
i = 5676026
}, {
i = 12819616
}, {
i = 72935811
}, {
i = 13186208
}, {
i = 32121872
}}
#31 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#32 0x0000000000580cdd in eval_sub (form=...) at eval.c:2119
args_left = {
i = 28755523
}
numargs = <optimized out>
val = <optimized out>
original_fun = {
i = 32880
}
original_args = {
i = 28755523
}
count = 36
argvals = {{
i = 72935811
}, {
i = 140737488338480
}, {
i = 1
}, {
i = 5792413
}, {
i = 38496
}, {
i = 140737488338592
}, {
i = 25680
}, {
i = 5790749
}}
#33 0x0000000000584ee9 in Fif (args=...) at eval.c:383
cond = <optimized out>
#34 0x0000000000580cdd in eval_sub (form=...) at eval.c:2119
args_left = {
i = 28755443
}
numargs = <optimized out>
val = <optimized out>
original_fun = {
i = 22272
}
original_args = {
i = 28755443
}
count = 35
argvals = {{
i = 13024576
}, {
i = 32121872
}, {
i = 140737488338816
}, {
i = 5681029
}, {
i = 12839296
}, {
i = 4294967296
}, {
i = 0
}, {
i = 13024576
}}
#35 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#36 0x000000000058627a in Flet (args=...) at eval.c:946
temps = 0x7fffffffbf80
tem = <optimized out>
lexenv = <optimized out>
elt = <optimized out>
varlist = <optimized out>
argnum = 2
sa_avail = <optimized out>
sa_must_free = false
#37 0x0000000000580cdd in eval_sub (form=...) at eval.c:2119
args_left = {
i = 28755203
}
numargs = <optimized out>
val = <optimized out>
original_fun = {
i = 25680
}
original_args = {
i = 28755203
}
count = 33
argvals = {{
i = 13024576
}, {
i = 32121872
}, {
i = 73256563
}, {
i = 5681029
}, {
i = 1
}, {
i = 4307437357
}, {
i = 140737488339232
}, {
i = 13024576
}}
#38 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#39 0x0000000000581ccf in funcall_lambda (fun=..., fun@entry=..., nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7fffffffc130)
at eval.c:2914
lexenv = {
i = 73256563
}
i = 2
optional = true
rest = false
#40 0x0000000000580823 in apply_lambda (fun=..., fun@entry=..., args=..., count=count@entry=31) at eval.c:2794
args_left = <optimized out>
i = 2
arg_vector = 0x7fffffffc130
tem = {
i = 32269491
}
sa_avail = <optimized out>
sa_must_free = false
#41 0x0000000000581593 in eval_sub (form=...) at eval.c:2241
val = <optimized out>
original_fun = {
i = 17617200
}
original_args = {
i = 32269475
}
count = 31
argvals = {{
i = 10
}, {
i = 31
}, {
i = 32267763
}, {
i = 5681029
}, {
i = 32263555
}, {
i = 4294967326
}, {
i = 6
}, {
i = 13024576
}}
#42 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#43 0x0000000000585ba1 in FletX (args=...) at eval.c:882
val = {
i = 85706228
}
lexenv = {
i = 73055459
}
#44 0x0000000000580cdd in eval_sub (form=...) at eval.c:2119
args_left = {
i = 32267763
}
numargs = <optimized out>
val = <optimized out>
original_fun = {
i = 25728
}
original_args = {
i = 32267763
}
count = 29
argvals = {{
i = 73011059
}, {
i = 29
}, {
i = 12839296
}, {
i = 73011059
}, {
i = 13024576
}, {
i = 32121872
}, {
i = 13024576
}, {
i = 5681029
}}
#45 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#46 0x0000000000580cdd in eval_sub (form=...) at eval.c:2119
args_left = {
i = 32267811
}
numargs = <optimized out>
val = <optimized out>
original_fun = {
i = 32880
}
original_args = {
i = 32267811
}
count = 28
argvals = {{
i = 0
}, {
i = 0
}, {
i = 140737488340160
}, {
i = 0
}, {
i = 0
}, {
i = 31086339
}, {
i = 0
}, {
i = 5774797
}}
#47 0x0000000000584ee9 in Fif (args=...) at eval.c:383
cond = <optimized out>
#48 0x0000000000580cdd in eval_sub (form=...) at eval.c:2119
args_left = {
i = 32267843
}
numargs = <optimized out>
val = <optimized out>
original_fun = {
i = 22272
}
original_args = {
i = 32267843
}
count = 27
argvals = {{
i = 13024576
}, {
i = 32121872
}, {
i = 73055459
}, {
i = 5681029
}, {
i = 4611686019484352512
}, {
i = 4294967296
}, {
i = 140737488340352
}, {
i = 13024576
}}
#49 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#50 0x0000000000581ccf in funcall_lambda (fun=..., fun@entry=..., nargs=nargs@entry=5, arg_vector=arg_vector@entry=0x7fffffffc590)
at eval.c:2914
lexenv = {
i = 73055459
}
i = 5
optional = false
rest = true
#51 0x0000000000580823 in apply_lambda (fun=..., fun@entry=..., args=..., count=count@entry=25) at eval.c:2794
args_left = <optimized out>
i = 5
arg_vector = 0x7fffffffc590
tem = {
i = 32551891
}
sa_avail = <optimized out>
sa_must_free = false
#52 0x0000000000581593 in eval_sub (form=...) at eval.c:2241
val = <optimized out>
original_fun = {
i = 16915728
}
original_args = {
i = 32551827
}
count = 25
argvals = {{
i = 13024576
}, {
i = 32121872
}, {
i = 140737488340736
}, {
i = 5681029
}, {
i = 83598368
}, {
i = 4300616505
}, {
i = 72934627
}, {
i = 13024576
}}
#53 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#54 0x000000000058627a in Flet (args=...) at eval.c:946
temps = 0x7fffffffc700
tem = <optimized out>
lexenv = <optimized out>
elt = <optimized out>
varlist = <optimized out>
argnum = 1
sa_avail = <optimized out>
sa_must_free = false
#55 0x0000000000580cdd in eval_sub (form=...) at eval.c:2119
args_left = {
i = 32548979
}
numargs = <optimized out>
val = <optimized out>
original_fun = {
i = 25680
}
original_args = {
i = 32548979
}
count = 23
argvals = {{
i = 32546563
}, {
i = 22
}, {
i = 51059348
}, {
i = 1
}, {
i = 140737488341104
}, {
i = 25920
}, {
i = 672
}, {
i = 1
}}
#56 0x000000000058172b in Fprogn (body=..., body@entry=...) at eval.c:426
No locals.
#57 0x000000000058633a in Fwhile (args=...) at eval.c:965
test = {
i = 3717920
}
body = {
i = 32549011
}
#58 0x0000000000580cdd in eval_sub (form=...) at eval.c:2119
args_left = {
i = 32549027
}
numargs = <optimized out>
val = <optimized out>
original_fun = {
i = 178912
}
original_args = {
i = 32549027
}
count = 22
argvals = {{
i = 13024576
}, {
i = 32121872
}, {
i = 140737488341312
}, {
i = 5681029
}, {
i = 16751933
}, {
i = 4300616458
}, {
i = 28727248
}, {
i = 13024576
}}
#59 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#60 0x000000000058627a in Flet (args=...) at eval.c:946
temps = 0x7fffffffc940
tem = <optimized out>
lexenv = <optimized out>
elt = <optimized out>
varlist = <optimized out>
argnum = 1
sa_avail = <optimized out>
sa_must_free = false
#61 0x0000000000580cdd in eval_sub (form=...) at eval.c:2119
args_left = {
i = 32549075
}
numargs = <optimized out>
val = <optimized out>
original_fun = {
i = 25680
}
original_args = {
i = 32549075
}
count = 20
argvals = {{
i = 6
}, {
i = 20
}, {
i = 29977284
}, {
i = 72935475
}, {
i = 1
}, {
i = 140737488341552
}, {
i = 1
}, {
i = 5792413
}}
#62 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#63 0x0000000000584f43 in Fif (args=...) at eval.c:384
cond = <optimized out>
#64 0x0000000000580cdd in eval_sub (form=...) at eval.c:2119
args_left = {
i = 32548179
}
numargs = <optimized out>
val = <optimized out>
original_fun = {
i = 22272
}
original_args = {
i = 32548179
}
count = 19
argvals = {{
i = 13024576
}, {
i = 32121872
}, {
i = 72934627
}, {
i = 5681029
}, {
i = 4611686019484352512
}, {
i = 4300648366
}, {
i = 23760
}, {
i = 13024576
}}
#65 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#66 0x0000000000581ccf in funcall_lambda (fun=..., fun@entry=..., nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffffffcc88)
at eval.c:2914
lexenv = {
i = 72934627
}
i = 1
optional = false
rest = false
#67 0x000000000058287c in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffcc80) at eval.c:2754
numargs = 1
val = <optimized out>
internal_args = <optimized out>
count = 17
#68 0x0000000000582990 in call1 (fn=..., fn@entry=..., arg1=...) at eval.c:2552
No locals.
#69 0x000000000058f1e8 in mapcar1 (leni=1, vals=vals@entry=0x0, fn=fn@entry=..., seq=..., seq@entry=...) at fns.c:2522
dummy = <optimized out>
i = 0
#70 0x000000000058f481 in Fmapc (function=..., sequence=...) at fns.c:2606
No locals.
#71 0x0000000000581168 in eval_sub (form=...) at eval.c:2169
i = 2
maxargs = 2
args_left = {
i = 0
}
numargs = <optimized out>
val = <optimized out>
original_fun = <optimized out>
original_args = {
i = 32280339
}
count = 16
argvals = {{
i = 16916416
}, {
i = 72935475
}, {
i = 51059348
}, {
i = 8854916
}, {
i = 6
}, {
i = 16
}, {
i = 51059348
}, {
i = 51059348
}}
#72 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#73 0x0000000000584ff4 in Fcond (args=...) at eval.c:408
clause = {
i = 32280275
}
val = <optimized out>
#74 0x0000000000580cdd in eval_sub (form=...) at eval.c:2119
args_left = {
i = 32281075
}
numargs = <optimized out>
val = <optimized out>
original_fun = {
i = 178480
}
original_args = {
i = 32281075
}
count = 15
argvals = {{
i = 2
}, {
i = 62
}, {
i = 0
}, {
i = 51059348
}, {
i = 4611686019484352512
}, {
i = 4294967296
}, {
i = 4611686018628714496
}, {
i = 13024576
}}
#75 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#76 0x0000000000581ccf in funcall_lambda (fun=..., fun@entry=..., nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffffffd008)
at eval.c:2914
lexenv = {
i = 72935715
}
i = 1
optional = false
rest = false
#77 0x000000000058287c in Ffuncall (nargs=2, args=<optimized out>) at eval.c:2754
numargs = 1
val = <optimized out>
internal_args = <optimized out>
count = 13
#78 0x0000000000580f28 in eval_sub (form=...) at eval.c:2137
vals = 0x7fffffffd000
argnum = <optimized out>
sa_avail = <optimized out>
sa_must_free = false
args_left = {
i = 0
}
numargs = <optimized out>
val = <optimized out>
original_fun = <optimized out>
original_args = {
i = 28683219
}
count = 12
argvals = {{
i = 4611686018595160064
}, {
i = 4368563
}, {
i = 140737488343136
}, {
i = 5680457
}, {
i = 31898211
}, {
i = 727700
}, {
i = 2636960
}, {
i = 0
}}
#79 0x0000000000584ee9 in Fif (args=...) at eval.c:383
cond = <optimized out>
#80 0x0000000000580cdd in eval_sub (form=...) at eval.c:2119
args_left = {
i = 28683283
}
numargs = <optimized out>
val = <optimized out>
original_fun = {
i = 22272
}
original_args = {
i = 28683283
}
count = 11
argvals = {{
i = 32721841
}, {
i = 744762
}, {
i = 140737488343472
}, {
i = 5681029
}, {
i = 16691872
}, {
i = 4300737269
}, {
i = 16692656
}, {
i = 13024576
}}
#81 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#82 0x000000000058627a in Flet (args=...) at eval.c:946
temps = 0x7fffffffd1b0
tem = <optimized out>
lexenv = <optimized out>
elt = <optimized out>
varlist = <optimized out>
argnum = 1
sa_avail = <optimized out>
sa_must_free = false
#83 0x0000000000580cdd in eval_sub (form=...) at eval.c:2119
args_left = {
i = 28683571
}
numargs = <optimized out>
val = <optimized out>
original_fun = {
i = 25680
}
original_args = {
i = 28683571
}
count = 9
argvals = {{
i = 10
}, {
i = 9
}, {
i = 32688
}, {
i = 6218583
}, {
i = 41744009
}, {
i = 32688
}, {
i = 0
}, {
i = 140737488343952
}}
#84 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#85 0x0000000000584f43 in Fif (args=...) at eval.c:384
cond = <optimized out>
#86 0x0000000000580cdd in eval_sub (form=...) at eval.c:2119
args_left = {
i = 28683987
}
numargs = <optimized out>
val = <optimized out>
original_fun = {
i = 22272
}
original_args = {
i = 28683987
}
count = 8
argvals = {{
i = 13024576
}, {
i = 32121872
}, {
i = 31174227
}, {
i = 5681029
}, {
i = 4611686018595160064
}, {
i = 4300647753
}, {
i = 4618944
}, {
i = 13024576
}}
#87 0x000000000058172b in Fprogn (body=...) at eval.c:426
No locals.
#88 0x0000000000581ccf in funcall_lambda (fun=..., fun@entry=..., nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x7fffffffd6e0)
at eval.c:2914
lexenv = {
i = 31174227
}
i = 0
optional = false
rest = false
#89 0x000000000058287c in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x7fffffffd6d8) at eval.c:2754
numargs = 0
val = <optimized out>
internal_args = <optimized out>
count = 6
#90 0x000000000057c453 in Ffuncall_interactively (nargs=1, args=0x7fffffffd6d8) at callint.c:248
No locals.
#91 0x00000000005821db in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffd6d0) at eval.c:2673
numargs = 1
val = <optimized out>
internal_args = <optimized out>
count = 4
#92 0x0000000000583c3c in Fapply (nargs=nargs@entry=3, args=args@entry=0x7fffffffd6d0) at eval.c:2274
i = <optimized out>
numargs = <optimized out>
funcall_nargs = <optimized out>
funcall_args = 0x0
spread_arg = {
i = 0
}
fun = <optimized out>
retval = <optimized out>
sa_avail = 16384
sa_must_free = false
#93 0x000000000057cd54 in Fcall_interactively (function=..., record_flag=..., keys=...) at callint.c:385
input = {
i = 0
}
events = <optimized out>
args = <optimized out>
visargs = <optimized out>
specs = {
i = 0
}
teml = <optimized out>
sa_avail = 16384
sa_must_free = false
next_event = <optimized out>
prefix_arg = <optimized out>
string = 0x0
tem = <optimized out>
varies = <optimized out>
i = <optimized out>
nargs = <optimized out>
mark = <optimized out>
arg_from_tty = false
key_count = 1
record_then_fail = false
save_this_command = <optimized out>
save_last_command = <optimized out>
save_this_original_command = <optimized out>
save_real_this_command = <optimized out>
#94 0x000000000058254c in Ffuncall (nargs=nargs@entry=4, args=args@entry=0x7fffffffd818) at eval.c:2700
internal_argbuf = {{
i = 16692320
}, {
i = 0
}, {
i = 13190400
}, {
i = 32121872
}, {
i = 1
}, {
i = 5681029
}, {
i = 4
}, {
i = 5649209
}}
numargs = 3
val = <optimized out>
internal_args = 0x7fffffffd820
count = 3
#95 0x00000000005d17a1 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., args_template@entry=...,
nargs=nargs@entry=1, args=<optimized out>, args@entry=0x7fffffffd9f8) at bytecode.c:880
targets = {0x5d3ed3 <exec_byte_code+12445>, 0x5d3f16 <exec_byte_code+12512>, 0x5d3f18 <exec_byte_code+12514>,
0x5d3f22 <exec_byte_code+12524>, 0x5d3f24 <exec_byte_code+12526>, 0x5d3f24 <exec_byte_code+12526>,
0x5d3f5b <exec_byte_code+12581>, 0x5d3f9b <exec_byte_code+12645>, 0x5d1217 <exec_byte_code+993>, 0x5d1219 <exec_byte_code+995>,
0x5d121b <exec_byte_code+997>, 0x5d1222 <exec_byte_code+1004>, 0x5d1224 <exec_byte_code+1006>, 0x5d1224 <exec_byte_code+1006>,
0x5d122a <exec_byte_code+1012>, 0x5d11f2 <exec_byte_code+956>, 0x5d155c <exec_byte_code+1830>, 0x5d155e <exec_byte_code+1832>,
0x5d1560 <exec_byte_code+1834>, 0x5d1562 <exec_byte_code+1836>, 0x5d1564 <exec_byte_code+1838>, 0x5d1564 <exec_byte_code+1838>,
0x5d158f <exec_byte_code+1881>, 0x5d156a <exec_byte_code+1844>, 0x5d16fe <exec_byte_code+2248>, 0x5d1700 <exec_byte_code+2250>,
0x5d1702 <exec_byte_code+2252>, 0x5d1704 <exec_byte_code+2254>, 0x5d1706 <exec_byte_code+2256>, 0x5d1706 <exec_byte_code+2256>,
0x5d16c7 <exec_byte_code+2193>, 0x5d16d9 <exec_byte_code+2211>, 0x5d177b <exec_byte_code+2373>, 0x5d177d <exec_byte_code+2375>,
0x5d177f <exec_byte_code+2377>, 0x5d1782 <exec_byte_code+2380>, 0x5d1784 <exec_byte_code+2382>, 0x5d1784 <exec_byte_code+2382>,
0x5d1744 <exec_byte_code+2318>, 0x5d1756 <exec_byte_code+2336>, 0x5d17fb <exec_byte_code+2501>, 0x5d17fd <exec_byte_code+2503>,
0x5d17ff <exec_byte_code+2505>, 0x5d1802 <exec_byte_code+2508>, 0x5d1804 <exec_byte_code+2510>, 0x5d1804 <exec_byte_code+2510>,
0x5d17c4 <exec_byte_code+2446>, 0x5d17d6 <exec_byte_code+2464>, 0x5d22d1 <exec_byte_code+5275>, 0x5d21fd <exec_byte_code+5063>,
0x5d21f6 <exec_byte_code+5056>, 0x5d3ed3 <exec_byte_code+12445>, 0x5d3ed3 <exec_byte_code+12445>,
0x5d3ed3 <exec_byte_code+12445>, 0x5d3ed3 <exec_byte_code+12445>, 0x5d3ed3 <exec_byte_code+12445>,
0x5d2454 <exec_byte_code+5662>, 0x5d2537 <exec_byte_code+5889>, 0x5d256c <exec_byte_code+5942>, 0x5d25a6 <exec_byte_code+6000>,
0x5d25e0 <exec_byte_code+6058>, 0x5d146e <exec_byte_code+1592>, 0x5d14b0 <exec_byte_code+1658>, 0x5d2620 <exec_byte_code+6122>,
0x5d13f9 <exec_byte_code+1475>, 0x5d14e7 <exec_byte_code+1713>, 0x5d2656 <exec_byte_code+6176>, 0x5d268d <exec_byte_code+6231>,
0x5d26b8 <exec_byte_code+6274>, 0x5d26ef <exec_byte_code+6329>, 0x5d2723 <exec_byte_code+6381>, 0x5d279c <exec_byte_code+6502>,
0x5d27c7 <exec_byte_code+6545>, 0x5d27fe <exec_byte_code+6600>, 0x5d2839 <exec_byte_code+6659>, 0x5d2864 <exec_byte_code+6702>,
0x5d288f <exec_byte_code+6745>, 0x5d28c6 <exec_byte_code+6800>, 0x5d28fd <exec_byte_code+6855>, 0x5d2934 <exec_byte_code+6910>,
0x5d296f <exec_byte_code+6969>, 0x5d29a3 <exec_byte_code+7021>, 0x5d29d7 <exec_byte_code+7073>, 0x5d2a50 <exec_byte_code+7194>,
0x5d2a96 <exec_byte_code+7264>, 0x5d2adc <exec_byte_code+7334>, 0x5d2d83 <exec_byte_code+8013>, 0x5d2dbf <exec_byte_code+8073>,
0x5d2dfb <exec_byte_code+8133>, 0x5d2e37 <exec_byte_code+8193>, 0x5d2e73 <exec_byte_code+8253>, 0x5d2ea7 <exec_byte_code+8305>,
0x5d2ef4 <exec_byte_code+8382>, 0x5d2f28 <exec_byte_code+8434>, 0x5d2f5c <exec_byte_code+8486>, 0x5d2f90 <exec_byte_code+8538>,
0x5d302f <exec_byte_code+8697>, 0x5d20f7 <exec_byte_code+4801>, 0x5d3098 <exec_byte_code+8802>, 0x5d30c3 <exec_byte_code+8845>,
0x5d3138 <exec_byte_code+8962>, 0x5d31a1 <exec_byte_code+9067>, 0x5d320a <exec_byte_code+9172>, 0x5d3235 <exec_byte_code+9215>,
0x5d3261 <exec_byte_code+9259>, 0x5d328d <exec_byte_code+9303>, 0x5d32ed <exec_byte_code+9399>, 0x5d3ed3 <exec_byte_code+12445>,
0x5d331d <exec_byte_code+9447>, 0x5d3349 <exec_byte_code+9491>, 0x5d3375 <exec_byte_code+9535>, 0x5d33a1 <exec_byte_code+9579>,
0x5d33cd <exec_byte_code+9623>, 0x5d33f9 <exec_byte_code+9667>, 0x5d20f7 <exec_byte_code+4801>, 0x5d3ed3 <exec_byte_code+12445>,
0x5d3424 <exec_byte_code+9710>, 0x5d3462 <exec_byte_code+9772>, 0x5d348d <exec_byte_code+9815>, 0x5d34b8 <exec_byte_code+9858>,
0x5d34ef <exec_byte_code+9913>, 0x5d3526 <exec_byte_code+9968>, 0x5d3551 <exec_byte_code+10011>,
0x5d3872 <exec_byte_code+10812>, 0x5d38a9 <exec_byte_code+10867>, 0x5d38e0 <exec_byte_code+10922>,
0x5d3917 <exec_byte_code+10977>, 0x5d3943 <exec_byte_code+11021>, 0x5d3ed3 <exec_byte_code+12445>,
0x5d2076 <exec_byte_code+4672>, 0x5d1878 <exec_byte_code+2626>, 0x5d130d <exec_byte_code+1239>, 0x5d194c <exec_byte_code+2838>,
0x5d1a38 <exec_byte_code+3074>, 0x5d1b23 <exec_byte_code+3309>, 0x5d201c <exec_byte_code+4582>, 0x5d2052 <exec_byte_code+4636>,
0x5d169d <exec_byte_code+2151>, 0x5d20c5 <exec_byte_code+4751>, 0x5d2129 <exec_byte_code+4851>, 0x5d2188 <exec_byte_code+4946>,
0x5d21ba <exec_byte_code+4996>, 0x5d2303 <exec_byte_code+5325>, 0x5d234e <exec_byte_code+5400>, 0x5d2389 <exec_byte_code+5459>,
0x5d23fd <exec_byte_code+5575>, 0x5d184a <exec_byte_code+2580>, 0x5d396e <exec_byte_code+11064>,
0x5d39a9 <exec_byte_code+11123>, 0x5d39d4 <exec_byte_code+11166>, 0x5d39ff <exec_byte_code+11209>,
0x5d3a2a <exec_byte_code+11252>, 0x5d3a55 <exec_byte_code+11295>, 0x5d3a8c <exec_byte_code+11350>,
0x5d3ac3 <exec_byte_code+11405>, 0x5d3afa <exec_byte_code+11460>, 0x5d3b31 <exec_byte_code+11515>,
0x5d3c3e <exec_byte_code+11784>, 0x5d3c75 <exec_byte_code+11839>, 0x5d3cac <exec_byte_code+11894>,
0x5d3cd7 <exec_byte_code+11937>, 0x5d3d0e <exec_byte_code+11992>, 0x5d3d45 <exec_byte_code+12047>,
0x5d3da7 <exec_byte_code+12145>, 0x5d3e09 <exec_byte_code+12243>, 0x5d2fc4 <exec_byte_code+8590>,
0x5d2ff8 <exec_byte_code+8642>, 0x5d3e3d <exec_byte_code+12295>, 0x5d3e99 <exec_byte_code+12387>,
0x5d3ed3 <exec_byte_code+12445>, 0x5d1c0e <exec_byte_code+3544>, 0x5d1cc8 <exec_byte_code+3730>, 0x5d1d98 <exec_byte_code+3938>,
0x5d1e68 <exec_byte_code+4146>, 0x5d1f42 <exec_byte_code+4364>, 0x5d2757 <exec_byte_code+6433>, 0x5d2a0b <exec_byte_code+7125>,
0x5d30f3 <exec_byte_code+8893>, 0x5d3fef <exec_byte_code+12729>, 0x5d4032 <exec_byte_code+12796>,
0x5d3ed3 <exec_byte_code+12445>, 0x5d3ed3 <exec_byte_code+12445>, 0x5d4088 <exec_byte_code+12882>,
0x5d3ed3 <exec_byte_code+12445>, 0x5d3ed3 <exec_byte_code+12445>, 0x5d3ed3 <exec_byte_code+12445>,
0x5d3ed3 <exec_byte_code+12445>, 0x5d3ed3 <exec_byte_code+12445>, 0x5d3ed3 <exec_byte_code+12445>,
0x5d3ed3 <exec_byte_code+12445>, 0x5d3ed3 <exec_byte_code+12445>, 0x5d3ed3 <exec_byte_code+12445>,
0x5d40da <exec_byte_code+12964> <repeats 64 times>}
op = 3
vectorp = 0x9497e0 <pure+883328>
stack = {
pc = 0xb931c4 <pure+3282020> "\006\006\071\203\242",
byte_string = {
i = 9738172
},
byte_string_start = 0xb93149 <pure+3281897> "\306\020\211?\205\023",
next = 0x0
}
top = 0x7fffffffd818
type = <optimized out>
#96 0x0000000000581ab4 in funcall_lambda (fun=..., fun@entry=..., nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fffffffd9f8)
at eval.c:2855
size = <optimized out>
lexenv = <optimized out>
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
#97 0x00000000005827ea in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffffffd9f0) at eval.c:2742
numargs = 1
val = <optimized out>
internal_args = <optimized out>
count = 2
#98 0x0000000000582990 in call1 (fn=..., fn@entry=..., arg1=...) at eval.c:2552
No locals.
#99 0x00000000004f6a54 in command_loop_1 () at keyboard.c:1457
cmd = {
i = 16692320
}
keybuf = {{
i = 54
}, {
i = 2
}, {
i = 410
}, {
i = 462
}, {
i = 506
}, {
i = 5681029
}, {
i = 140737488345872
}, {
i = 5772411
}, {
i = 0
}, {
i = 0
}, {
i = 0
}, {
i = 84490947
}, {
i = 0
}, {
i = 84490947
}, {
i = 0
}, {
i = 0
}, {
i = 0
}, {
i = 5787022
}, {
i = 137312
}, {
i = 84490947
}, {
i = 8854916
}, {
i = 19728
}, {
i = 0
}, {
i = 5141838
}, {
i = 0
}, {
i = 5142091
}, {
i = 18164736
}, {
i = 4002
}, {
i = 0
}, {
i = 0
}}
i = <optimized out>
prev_modiff = 27659
prev_buffer = 0x1ea2410
#100 0x000000000057fc0f in internal_condition_case (bfun=bfun@entry=0x4f6244 <command_loop_1>, handlers=..., handlers@entry=...,
hfun=hfun@entry=0x4e755b <cmd_error>) at eval.c:1309
val = {
i = 7
}
c = <optimized out>
#101 0x00000000004e024e in command_loop_2 (ignore=..., ignore@entry=...) at keyboard.c:1086
val = <optimized out>
#102 0x000000000057fb94 in internal_catch (tag=..., tag@entry=..., func=func@entry=0x4e0236 <command_loop_2>, arg=..., arg@entry=...)
at eval.c:1074
val = {
i = 7
}
c = <optimized out>
#103 0x00000000004e01f4 in command_loop () at keyboard.c:1065
No locals.
#104 0x00000000004e6fae in recursive_edit_1 () at keyboard.c:671
val = <optimized out>
#105 0x00000000004e7495 in Frecursive_edit () at keyboard.c:742
No locals.
#106 0x00000000004df8f1 in main (argc=<optimized out>, argv=0x7fffffffdd58) at emacs.c:1656
dummy = {
i = 1
}
stack_bottom_variable = 0 '\000'
do_initial_setlocale = <optimized out>
dumping = false
skip_args = 0
rlim = {
rlim_cur = 8720000,
rlim_max = 18446744073709551615
}
no_loadup = false
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
original_pwd = 0x0
Lisp Backtrace:
"abs" (0xffffb170)
">=" (0xffffb290)
"and" (0xffffb360)
"if" (0xffffb430)
0x48370c0 Lisp type 3
"funcall" (0xffffb5b0)
"cond" (0xffffb720)
0x4836fc0 Lisp type 3
"mapcar" (0xffffb990)
"let*" (0xffffbae0)
"lui-adjust-undo-list" (0xffffbba0)
"setq" (0xffffbd80)
"progn" (0xffffbe50)
"if" (0xffffbf20)
"let" (0xffffc070)
"lui-insert" (0xffffc130)
"let*" (0xffffc330)
"progn" (0xffffc400)
"if" (0xffffc4d0)
"circe-display" (0xffffc590)
"let" (0xffffc7f0)
"while" (0xffffc8e0)
"let" (0xffffca30)
"if" (0xffffcb10)
"circe-command-SAY" (0xffffcc88)
"mapc" (0xffffcd50)
"cond" (0xffffce80)
"circe--input" (0xffffd008)
"funcall" (0xffffd000)
"if" (0xffffd150)
"let" (0xffffd2a0)
"if" (0xffffd380)
"lui-send-input" (0xffffd6e0)
"funcall-interactively" (0xffffd6d8)
"call-interactively" (0xffffd820)
"command-execute" (0xffffd9f8)
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: 25.1.50; segfault while running circe
[not found] ` <83h9jrbl7b.fsf@gnu.org>
@ 2015-12-09 19:13 ` Eric Hanchrow
0 siblings, 0 replies; 24+ messages in thread
From: Eric Hanchrow @ 2015-12-09 19:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22120, jwiegley
[-- Attachment #1: Type: text/plain, Size: 267 bytes --]
On Wed, Dec 9, 2015 at 9:12 AM Eli Zaretskii <eliz@gnu.org> wrote:
> Thanks, but again please show the offending value(s).
>
'f' was -1.
> Do I understand correctly that the same code normally works for you,
> and only segfaults once in a while?
>
That's right.
[-- Attachment #2: Type: text/html, Size: 690 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: Another backtrace
2015-12-08 20:19 bug#22120: 25.1.50; segfault while running circe Eric Hanchrow
2015-12-08 20:33 ` Eli Zaretskii
2015-12-08 20:36 ` John Wiegley
@ 2015-12-10 18:42 ` Eric Hanchrow
2015-12-10 19:02 ` Eli Zaretskii
2015-12-12 22:37 ` Eric Hanchrow
3 siblings, 1 reply; 24+ messages in thread
From: Eric Hanchrow @ 2015-12-10 18:42 UTC (permalink / raw)
To: 22120@debbugs.gnu.org
[-- Attachment #1.1: Type: text/plain, Size: 67 bytes --]
What little I could get of the variables' values is at the bottom.
[-- Attachment #1.2: Type: text/html, Size: 107 bytes --]
[-- Attachment #2: gdb.txt.gz --]
[-- Type: application/x-gzip, Size: 5472 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: Another backtrace
2015-12-10 18:42 ` bug#22120: Another backtrace Eric Hanchrow
@ 2015-12-10 19:02 ` Eli Zaretskii
2015-12-10 19:15 ` Eric Hanchrow
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2015-12-10 19:02 UTC (permalink / raw)
To: Eric Hanchrow; +Cc: 22120
> From: Eric Hanchrow <eric.hanchrow@gmail.com>
> Date: Thu, 10 Dec 2015 18:42:19 +0000
>
> What little I could get of the variables' values is at the bottom.
It doesn't tell much.
Can you try reproducing this in an unoptimized build? It's very hard
to debug optimized code when we suspect some more or less random
corruption of values. If the problem happens in an unoptimized build,
we won't need to look so hard for bad values.
Also, it looks like you configured with --enable-check-lisp-object-type,
is that right? If so, please configure without it, that would allow
to see many values directly in the backtrace, instead of asking you to
print them in GDB.
Thanks.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: Another backtrace
2015-12-10 19:02 ` Eli Zaretskii
@ 2015-12-10 19:15 ` Eric Hanchrow
2015-12-10 19:30 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: Eric Hanchrow @ 2015-12-10 19:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22120
[-- Attachment #1: Type: text/plain, Size: 972 bytes --]
On Thu, Dec 10, 2015 at 11:02 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Eric Hanchrow <eric.hanchrow@gmail.com>
> > Date: Thu, 10 Dec 2015 18:42:19 +0000
> >
> > What little I could get of the variables' values is at the bottom.
>
> It doesn't tell much.
>
> Can you try reproducing this in an unoptimized build?
I was under the impression that this build _was_ unoptimized (so I was
surprised to see those variables "optimized out"). I configured with
$ ./configure --enable-checking --enable-check-lisp-object-type
--config-cache CFLAGS=-Og -g3
Maybe I should add -O0 to CFLAGS. (I got those options from a recent
thread on emacs-devel about a proposed new file etc/DEBUG).
> Also, it looks like you configured with --enable-check-lisp-object-type,
> is that right?
Yes.
> If so, please configure without it, that would allow
> to see many values directly in the backtrace, instead of asking you to
> print them in GDB.
>
Oho! OK.
>
> Thanks.
>
[-- Attachment #2: Type: text/html, Size: 1840 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: Another backtrace
2015-12-10 19:15 ` Eric Hanchrow
@ 2015-12-10 19:30 ` Eli Zaretskii
0 siblings, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2015-12-10 19:30 UTC (permalink / raw)
To: Eric Hanchrow; +Cc: 22120
> From: Eric Hanchrow <eric.hanchrow@gmail.com>
> Date: Thu, 10 Dec 2015 19:15:52 +0000
> Cc: 22120@debbugs.gnu.org
>
> Can you try reproducing this in an unoptimized build?
>
> I was under the impression that this build _was_ unoptimized (so I was
> surprised to see those variables "optimized out"). I configured with
>
> $ ./configure --enable-checking --enable-check-lisp-object-type --config-cache
> CFLAGS=-Og -g3
>
> Maybe I should add -O0 to CFLAGS.
Yes, please. -Og does not prevent all of the optimizations, it just
prevents some of the more aggressive ones.
> (I got those options from a recent thread on emacs-devel about a
> proposed new file etc/DEBUG).
You may wish to re-read the beginning of that file, it says more about
this now ;-)
Thanks.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: Another backtrace
2015-12-08 20:19 bug#22120: 25.1.50; segfault while running circe Eric Hanchrow
` (2 preceding siblings ...)
2015-12-10 18:42 ` bug#22120: Another backtrace Eric Hanchrow
@ 2015-12-12 22:37 ` Eric Hanchrow
2015-12-13 15:27 ` Eli Zaretskii
3 siblings, 1 reply; 24+ messages in thread
From: Eric Hanchrow @ 2015-12-12 22:37 UTC (permalink / raw)
To: 22120@debbugs.gnu.org
[-- Attachment #1.1: Type: text/plain, Size: 130 bytes --]
It's starting to look like "lui-adjust-undo-list" might be culpable; I
think I've seen that function on the lisp stack each time.
[-- Attachment #1.2: Type: text/html, Size: 169 bytes --]
[-- Attachment #2: gdb.txt.gz --]
[-- Type: application/x-gzip, Size: 9826 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: Another backtrace
2015-12-12 22:37 ` Eric Hanchrow
@ 2015-12-13 15:27 ` Eli Zaretskii
2015-12-13 17:54 ` Eric Hanchrow
2015-12-24 3:24 ` Eric Hanchrow
0 siblings, 2 replies; 24+ messages in thread
From: Eli Zaretskii @ 2015-12-13 15:27 UTC (permalink / raw)
To: Eric Hanchrow; +Cc: 22120
> From: Eric Hanchrow <eric.hanchrow@gmail.com>
> Date: Sat, 12 Dec 2015 22:37:08 +0000
>
> It's starting to look like "lui-adjust-undo-list" might be culpable; I think
> I've seen that function on the lisp stack each time.
Looks like another reincarnation of bug#21667.
Can you modify lui-adjust-undo-list so that GC is inhibited (by
binding gc-cons-threshold to most-positive-fixnum around the whole
function)? It looks dangerous to me that this function messes with
the undo list inside mapconcat, which could cause GC, which could
decide to compact the current buffer, including shortening its undo
list, while lui-adjust-undo-list modifies it.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: Another backtrace
2015-12-13 15:27 ` Eli Zaretskii
@ 2015-12-13 17:54 ` Eric Hanchrow
2015-12-13 18:04 ` Eli Zaretskii
2015-12-24 3:24 ` Eric Hanchrow
1 sibling, 1 reply; 24+ messages in thread
From: Eric Hanchrow @ 2015-12-13 17:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22120
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]
On Sun, Dec 13, 2015 at 7:27 AM Eli Zaretskii <eliz@gnu.org> wrote:
> Looks like another reincarnation of bug#21667.
>
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21667 appears to be unrelated
to this one. I suspect you made a typo.
> Can you modify lui-adjust-undo-list so that GC is inhibited (by
> binding gc-cons-threshold to most-positive-fixnum around the whole
> function)?
OK, I've done that. If that works, it'll take days of use before I'm
confident that it did work (because the bug only appears once every few
days); can you think of some sort of debug message I can stick in there
that can tell us that you've correctly guessed the cause?
[-- Attachment #2: Type: text/html, Size: 1141 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: Another backtrace
2015-12-13 17:54 ` Eric Hanchrow
@ 2015-12-13 18:04 ` Eli Zaretskii
2015-12-13 18:07 ` Eric Hanchrow
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2015-12-13 18:04 UTC (permalink / raw)
To: Eric Hanchrow; +Cc: 22120
> From: Eric Hanchrow <eric.hanchrow@gmail.com>
> Date: Sun, 13 Dec 2015 17:54:04 +0000
> Cc: 22120@debbugs.gnu.org
>
> Looks like another reincarnation of bug#21667.
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21667 appears to be unrelated to
> this one. I suspect you made a typo.
Sorry, I meant 21666.
> Can you modify lui-adjust-undo-list so that GC is inhibited (by
> binding gc-cons-threshold to most-positive-fixnum around the whole
> function)?
>
> OK, I've done that. If that works, it'll take days of use before I'm confident
> that it did work (because the bug only appears once every few days); can you
> think of some sort of debug message I can stick in there that can tell us that
> you've correctly guessed the cause?
No, I don't think it's possible, not during GC anyway.
There's no hurry, so waiting for this to happen is fine. Thanks.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: Another backtrace
2015-12-13 18:04 ` Eli Zaretskii
@ 2015-12-13 18:07 ` Eric Hanchrow
2015-12-13 18:13 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: Eric Hanchrow @ 2015-12-13 18:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22120
[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]
I'm surprised that it is possible to cause a segfault from lisp. Is that
an indication of a problem in the core C code, or is that just the way
things are?
On Sun, Dec 13, 2015 at 10:04 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Eric Hanchrow <eric.hanchrow@gmail.com>
> > Date: Sun, 13 Dec 2015 17:54:04 +0000
> > Cc: 22120@debbugs.gnu.org
> >
> > Looks like another reincarnation of bug#21667.
> >
> > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21667 appears to be
> unrelated to
> > this one. I suspect you made a typo.
>
> Sorry, I meant 21666.
>
> > Can you modify lui-adjust-undo-list so that GC is inhibited (by
> > binding gc-cons-threshold to most-positive-fixnum around the whole
> > function)?
> >
> > OK, I've done that. If that works, it'll take days of use before I'm
> confident
> > that it did work (because the bug only appears once every few days); can
> you
> > think of some sort of debug message I can stick in there that can tell
> us that
> > you've correctly guessed the cause?
>
> No, I don't think it's possible, not during GC anyway.
>
> There's no hurry, so waiting for this to happen is fine. Thanks.
>
[-- Attachment #2: Type: text/html, Size: 1775 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: Another backtrace
2015-12-13 18:07 ` Eric Hanchrow
@ 2015-12-13 18:13 ` Eli Zaretskii
2015-12-13 18:19 ` Eric Hanchrow
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2015-12-13 18:13 UTC (permalink / raw)
To: Eric Hanchrow; +Cc: 22120
> From: Eric Hanchrow <eric.hanchrow@gmail.com>
> Date: Sun, 13 Dec 2015 18:07:43 +0000
> Cc: 22120@debbugs.gnu.org
>
> I'm surprised that it is possible to cause a segfault from lisp. Is that an
> indication of a problem in the core C code, or is that just the way things are?
That's what you get for messing with undo-list.
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: Another backtrace
2015-12-13 18:13 ` Eli Zaretskii
@ 2015-12-13 18:19 ` Eric Hanchrow
2015-12-13 18:22 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: Eric Hanchrow @ 2015-12-13 18:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22120
[-- Attachment #1: Type: text/plain, Size: 598 bytes --]
I glanced through (info "(elisp) Undo") and didn't see any sort of
warning. Should we add one? I can certainly stick something in there
myself, but doubt it'd be quite correct.
On Sun, Dec 13, 2015 at 10:13 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Eric Hanchrow <eric.hanchrow@gmail.com>
> > Date: Sun, 13 Dec 2015 18:07:43 +0000
> > Cc: 22120@debbugs.gnu.org
> >
> > I'm surprised that it is possible to cause a segfault from lisp. Is that
> an
> > indication of a problem in the core C code, or is that just the way
> things are?
>
> That's what you get for messing with undo-list.
>
[-- Attachment #2: Type: text/html, Size: 1024 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: Another backtrace
2015-12-13 18:19 ` Eric Hanchrow
@ 2015-12-13 18:22 ` Eli Zaretskii
2015-12-13 18:29 ` Eric Hanchrow
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2015-12-13 18:22 UTC (permalink / raw)
To: Eric Hanchrow; +Cc: 22120
> From: Eric Hanchrow <eric.hanchrow@gmail.com>
> Date: Sun, 13 Dec 2015 18:19:52 +0000
> Cc: 22120@debbugs.gnu.org
>
> I glanced through (info "(elisp) Undo") and didn't see any sort of warning.
> Should we add one? I can certainly stick something in there myself, but doubt
> it'd be quite correct.
Let's not get ahead of ourselves: first, let's see if my guess holds
any water, and only afterwards let's worry about documenting whatever
we find.
OK?
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: Another backtrace
2015-12-13 18:22 ` Eli Zaretskii
@ 2015-12-13 18:29 ` Eric Hanchrow
0 siblings, 0 replies; 24+ messages in thread
From: Eric Hanchrow @ 2015-12-13 18:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22120
[-- Attachment #1: Type: text/plain, Size: 569 bytes --]
Fair enough.
On Sun, Dec 13, 2015 at 10:22 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Eric Hanchrow <eric.hanchrow@gmail.com>
> > Date: Sun, 13 Dec 2015 18:19:52 +0000
> > Cc: 22120@debbugs.gnu.org
> >
> > I glanced through (info "(elisp) Undo") and didn't see any sort of
> warning.
> > Should we add one? I can certainly stick something in there myself, but
> doubt
> > it'd be quite correct.
>
> Let's not get ahead of ourselves: first, let's see if my guess holds
> any water, and only afterwards let's worry about documenting whatever
> we find.
>
> OK?
>
[-- Attachment #2: Type: text/html, Size: 1015 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: Another backtrace
2015-12-13 15:27 ` Eli Zaretskii
2015-12-13 17:54 ` Eric Hanchrow
@ 2015-12-24 3:24 ` Eric Hanchrow
2015-12-24 16:12 ` Eli Zaretskii
1 sibling, 1 reply; 24+ messages in thread
From: Eric Hanchrow @ 2015-12-24 3:24 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22120
[-- Attachment #1: Type: text/plain, Size: 855 bytes --]
I don't think I've seen a segfault since I made this change -- it must have
worked around the problem.
On Sun, Dec 13, 2015 at 7:27 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Eric Hanchrow <eric.hanchrow@gmail.com>
> > Date: Sat, 12 Dec 2015 22:37:08 +0000
> >
> > It's starting to look like "lui-adjust-undo-list" might be culpable; I
> think
> > I've seen that function on the lisp stack each time.
>
> Looks like another reincarnation of bug#21667.
>
> Can you modify lui-adjust-undo-list so that GC is inhibited (by
> binding gc-cons-threshold to most-positive-fixnum around the whole
> function)? It looks dangerous to me that this function messes with
> the undo list inside mapconcat, which could cause GC, which could
> decide to compact the current buffer, including shortening its undo
> list, while lui-adjust-undo-list modifies it.
>
[-- Attachment #2: Type: text/html, Size: 1242 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#22120: Another backtrace
2015-12-24 3:24 ` Eric Hanchrow
@ 2015-12-24 16:12 ` Eli Zaretskii
0 siblings, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2015-12-24 16:12 UTC (permalink / raw)
To: Eric Hanchrow; +Cc: 22120-done
> From: Eric Hanchrow <eric.hanchrow@gmail.com>
> Date: Thu, 24 Dec 2015 03:24:26 +0000
> Cc: 22120@debbugs.gnu.org
>
> I don't think I've seen a segfault since I made this change -- it must have
> worked around the problem.
Thanks, closing.
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2015-12-24 16:12 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-08 20:19 bug#22120: 25.1.50; segfault while running circe Eric Hanchrow
2015-12-08 20:33 ` Eli Zaretskii
2015-12-08 20:36 ` Eric Hanchrow
2015-12-08 20:54 ` Eli Zaretskii
2015-12-08 21:03 ` John Wiegley
2015-12-09 15:29 ` Eric Hanchrow
[not found] ` <83h9jrbl7b.fsf@gnu.org>
2015-12-09 19:13 ` Eric Hanchrow
2015-12-08 20:36 ` John Wiegley
2015-12-08 20:38 ` Eric Hanchrow
2015-12-10 18:42 ` bug#22120: Another backtrace Eric Hanchrow
2015-12-10 19:02 ` Eli Zaretskii
2015-12-10 19:15 ` Eric Hanchrow
2015-12-10 19:30 ` Eli Zaretskii
2015-12-12 22:37 ` Eric Hanchrow
2015-12-13 15:27 ` Eli Zaretskii
2015-12-13 17:54 ` Eric Hanchrow
2015-12-13 18:04 ` Eli Zaretskii
2015-12-13 18:07 ` Eric Hanchrow
2015-12-13 18:13 ` Eli Zaretskii
2015-12-13 18:19 ` Eric Hanchrow
2015-12-13 18:22 ` Eli Zaretskii
2015-12-13 18:29 ` Eric Hanchrow
2015-12-24 3:24 ` Eric Hanchrow
2015-12-24 16:12 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).