GNU bug report logs -
#48476
Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"
Previous Next
Reported by: Rob Browning <rlb <at> defaultvalue.org>
Date: Sun, 16 May 2021 22:51:02 UTC
Severity: normal
Merged with 60796
Found in version 27.1
Done: Michael Albinus <michael.albinus <at> gmx.de>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48476 in the body.
You can then email your comments to 48476 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48476
; Package
emacs
.
(Sun, 16 May 2021 22:51:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Rob Browning <rlb <at> defaultvalue.org>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 16 May 2021 22:51:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[When possible/appropriate, please preserve the 988581-forwarded address
in replies.]
Recently reported, and I can reproduce it locally with -Q (and with the
lucid flavor) too.
Thomas Lundqvist <tlundqvist <at> acm.org> writes:
> Package: emacs-gtk
> Version: 1:27.1+1-3.1
> Severity: normal
>
> Dear Maintainer,
>
> My emacs get stuck with 100% cpu when started from a directory ending with
> ".tar".
>
> For example, the following commands trigger the error:
> - mkdir test.tar
> - cd test.tar
> - emacs
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48476
; Package
emacs
.
(Mon, 17 May 2021 14:43:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 48476 <at> debbugs.gnu.org (full text, mbox):
Rob Browning <rlb <at> defaultvalue.org> writes:
>> My emacs get stuck with 100% cpu when started from a directory ending with
>> ".tar".
>>
>> For example, the following commands trigger the error:
>> - mkdir test.tar
>> - cd test.tar
>> - emacs
I can reproduce this on Debian/bullseye on the trunk, too -- Emacs uses
100% CPU and can't be interrupted with `C-g'.
strace seems to say that it's inflooping like this:
pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so.gz", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.elc", O_RDONLY|O_CLOEXEC) = 15
[pid 70536] fstat(15, {st_mode=S_IFREG|0644, st_size=24503, ...}) = 0
[pid 70536] read(15, ";ELC\33\0\0\0\n;;; Compiled\n;;; in Ema"..., 512) = 512
[pid 70536] lseek(15, 0, SEEK_SET) = 0
[pid 70536] newfstatat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.elc", {st_mode=S_IFREG|0644, st_size=24503, ...}, 0) = 0
[pid 70536] newfstatat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.el", {st_mode=S_IFREG|0644, st_size=28504, ...}, 0) = 0
[pid 70536] fcntl(15, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
[pid 70536] fstat(15, {st_mode=S_IFREG|0644, st_size=24503, ...}) = 0
[pid 70536] read(15, ";ELC\33\0\0\0\n;;; Compiled\n;;; in Ema"..., 4096) = 4096
[pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so.gz", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.elc", O_RDONLY|O_CLOEXEC) = 16
[pid 70536] fstat(16, {st_mode=S_IFREG|0644, st_size=24503, ...}) = 0
[pid 70536] read(16, ";ELC\33\0\0\0\n;;; Compiled\n;;; in Ema"..., 512) = 512
[pid 70536] lseek(16, 0, SEEK_SET) = 0
[pid 70536] newfstatat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.el", {st_mode=S_IFREG|0644, st_size=28504, ...}, 0) = 0
[pid 70536] fcntl(16, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
[pid 70536] fstat(16, {st_mode=S_IFREG|0644, st_size=24503, ...}) = 0
[pid 70536] read(16, ";ELC\33\0\0\0\n;;; Compiled\n;;; in Ema"..., 4096) = 4096
[pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so.gz", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.elc", O_RDONLY|O_CLOEXEC) = 17
[pid 70536] fstat(17, {st_mode=S_IFREG|0644, st_size=24503, ...}) = 0
[pid 70536] close(17) = 0
[pid 70536] close(16) = 0
[pid 70536] close(15) = 0
[pid 70536] close(14) = 0
[pid 70536] close(13) = 0
[pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
[pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so.gz", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
I have not tried to debug further, but this strace seems to indicate
that this might be Tramp-related, so I've added Michael to the CCs --
perhaps it'll be immediately obvious to him what the problem is. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48476
; Package
emacs
.
(Mon, 17 May 2021 15:26:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 48476 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 17 May 2021 16:42:33 +0200, Lars Ingebrigtsen <larsi <at> gnus.org> said:
Lars> Rob Browning <rlb <at> defaultvalue.org> writes:
>>> My emacs get stuck with 100% cpu when started from a directory ending with
>>> ".tar".
>>>
>>> For example, the following commands trigger the error:
>>> - mkdir test.tar
>>> - cd test.tar
>>> - emacs
Lars> I can reproduce this on Debian/bullseye on the trunk, too -- Emacs uses
Lars> 100% CPU and can't be interrupted with `C-g'.
Lars> strace seems to say that it's inflooping like this:
Lars> pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so.gz", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Lars> [pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.elc", O_RDONLY|O_CLOEXEC) = 15
Lars> [pid 70536] fstat(15, {st_mode=S_IFREG|0644, st_size=24503, ...}) = 0
Lars> [pid 70536] read(15, ";ELC\33\0\0\0\n;;; Compiled\n;;; in Ema"..., 512) = 512
Lars> [pid 70536] lseek(15, 0, SEEK_SET) = 0
Lars> [pid 70536] newfstatat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.elc", {st_mode=S_IFREG|0644, st_size=24503, ...}, 0) = 0
Lars> [pid 70536] newfstatat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.el", {st_mode=S_IFREG|0644, st_size=28504, ...}, 0) = 0
Lars> [pid 70536] fcntl(15, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
Lars> [pid 70536] fstat(15, {st_mode=S_IFREG|0644, st_size=24503, ...}) = 0
Lars> [pid 70536] read(15, ";ELC\33\0\0\0\n;;; Compiled\n;;; in Ema"..., 4096) = 4096
Lars> [pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Lars> [pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so.gz", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Lars> [pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.elc", O_RDONLY|O_CLOEXEC) = 16
Lars> [pid 70536] fstat(16, {st_mode=S_IFREG|0644, st_size=24503, ...}) = 0
Lars> [pid 70536] read(16, ";ELC\33\0\0\0\n;;; Compiled\n;;; in Ema"..., 512) = 512
Lars> [pid 70536] lseek(16, 0, SEEK_SET) = 0
Lars> [pid 70536] newfstatat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.el", {st_mode=S_IFREG|0644, st_size=28504, ...}, 0) = 0
Lars> [pid 70536] fcntl(16, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
Lars> [pid 70536] fstat(16, {st_mode=S_IFREG|0644, st_size=24503, ...}) = 0
Lars> [pid 70536] read(16, ";ELC\33\0\0\0\n;;; Compiled\n;;; in Ema"..., 4096) = 4096
Lars> [pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Lars> [pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so.gz", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Lars> [pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.elc", O_RDONLY|O_CLOEXEC) = 17
Lars> [pid 70536] fstat(17, {st_mode=S_IFREG|0644, st_size=24503, ...}) = 0
Lars> [pid 70536] close(17) = 0
Lars> [pid 70536] close(16) = 0
Lars> [pid 70536] close(15) = 0
Lars> [pid 70536] close(14) = 0
Lars> [pid 70536] close(13) = 0
Lars> [pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Lars> [pid 70536] openat(AT_FDCWD, "/home/larsi/src/emacs/trunk/lisp/net/tramp-archive.so.gz", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
I have a backtrace from gdb that might shed some light.
Michael, this is emacs signalling an error for a recursive load,
apparently forever. master has the same issue. I set a breakpoint at
lread.c:1366
{
int load_count = 0;
Lisp_Object tem = Vloads_in_progress;
FOR_EACH_TAIL_SAFE (tem)
if (!NILP (Fequal (found, XCAR (tem))) && (++load_count > 3))
-> signal_error ("Recursive load", Fcons (found, Vloads_in_progress));
record_unwind_protect (record_load_unwind, Vloads_in_progress);
Vloads_in_progress = Fcons (found, Vloads_in_progress);
}
and got this backtrace, which implicates
'tramp-archive-autoload-file-name-handler'
Thread 1 "emacs" hit Breakpoint 5, Fload (file=XIL(0x555556847f74), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=<optimized out>,
must_suffix=<optimized out>) at lread.c:1366
1366 signal_error ("Recursive load", Fcons (found, Vloads_in_progress));
(gdb) bt
#0 Fload (file=XIL(0x555556847f74), noerror=XIL(0), nomessage=XIL(0x30), nosuffix=<optimized out>, must_suffix=<optimized out>)
at lread.c:1366
#1 0x000055555572be5a in save_match_data_load
(file=XIL(0x555556847f74), noerror=noerror <at> entry=XIL(0), nomessage=nomessage <at> entry=XIL(0x30), nosuffix=nosuffix <at> entry=XIL(0), must_suffix=must_suffix <at> entry=XIL(0x30)) at lread.c:1616
#2 0x0000555555702881 in Fautoload_do_load (fundef=XIL(0x55555677e753), funname=XIL(0xbc9bd0), macro_only=XIL(0)) at eval.c:2308
#3 0x0000555555702af2 in Ffuncall (nargs=4, args=0x7fffffff92c0) at lisp.h:1002
#4 0x0000555555702d04 in call3 (fn=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>) at eval.c:2910
#5 0x00005555556b8d76 in Fexpand_file_name (name=XIL(0x55555649d1c4), default_directory=<optimized out>) at fileio.c:905
#6 0x000055555572ab71 in readevalloop
(readcharfun=XIL(0x7770), infile0=0x7fffffff9500, sourcename=XIL(0x55555649d1c4), printflag=false, unibyte=XIL(0), readfun=XIL(0), start=<optimized out>, end=XIL(0)) at lisp.h:1002
#7 0x000055555572bbb1 in Fload
(file=<optimized out>, noerror=XIL(0), nomessage=XIL(0x30), nosuffix=<optimized out>, must_suffix=<optimized out>) at lisp.h:1002
#8 0x000055555572be5a in save_match_data_load
(file=XIL(0x555556847f74), noerror=noerror <at> entry=XIL(0), nomessage=nomessage <at> entry=XIL(0x30), nosuffix=nosuffix <at> entry=XIL(0), must_suffix=must_suffix <at> entry=XIL(0x30)) at lread.c:1616
#9 0x0000555555702881 in Fautoload_do_load (fundef=XIL(0x55555677e753), funname=XIL(0xbc9bd0), macro_only=XIL(0)) at eval.c:2308
#10 0x0000555555702af2 in Ffuncall (nargs=4, args=0x7fffffff96b0) at lisp.h:1002
#11 0x0000555555702d04 in call3 (fn=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>) at eval.c:2910
#12 0x00005555556b8d76 in Fexpand_file_name (name=XIL(0x55555649cff4), default_directory=<optimized out>) at fileio.c:905
#13 0x000055555572ab71 in readevalloop
(readcharfun=XIL(0x7770), infile0=0x7fffffff98f0, sourcename=XIL(0x55555649cff4), printflag=false, unibyte=XIL(0), readfun=XIL(0), start=<optimized out>, end=XIL(0)) at lisp.h:1002
#14 0x000055555572bbb1 in Fload
(file=<optimized out>, noerror=XIL(0), nomessage=XIL(0x30), nosuffix=<optimized out>, must_suffix=<optimized out>) at lisp.h:1002
#15 0x000055555572be5a in save_match_data_load
(file=XIL(0x555556847f74), noerror=noerror <at> entry=XIL(0), nomessage=nomessage <at> entry=XIL(0x30), nosuffix=nosuffix <at> entry=XIL(0), must_suffix=must_suffix <at> entry=XIL(0x30)) at lread.c:1616
#16 0x0000555555702881 in Fautoload_do_load (fundef=XIL(0x55555677e753), funname=XIL(0xbc9bd0), macro_only=XIL(0)) at eval.c:2308
#17 0x0000555555702af2 in Ffuncall (nargs=4, args=0x7fffffff9aa0) at lisp.h:1002
#18 0x0000555555702d04 in call3 (fn=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>) at eval.c:2910
#19 0x00005555556b8d76 in Fexpand_file_name (name=XIL(0x55555649ce74), default_directory=<optimized out>) at fileio.c:905
#20 0x000055555572ab71 in readevalloop
(readcharfun=XIL(0x7770), infile0=0x7fffffff9ce0, sourcename=XIL(0x55555649ce74), printflag=false, unibyte=XIL(0), readfun=XIL(0), start=<optimized out>, end=XIL(0)) at lisp.h:1002
#21 0x000055555572bbb1 in Fload
(file=<optimized out>, noerror=XIL(0), nomessage=XIL(0x30), nosuffix=<optimized out>, must_suffix=<optimized out>) at lisp.h:1002
#22 0x000055555572be5a in save_match_data_load
(file=XIL(0x555556847f74), noerror=noerror <at> entry=XIL(0), nomessage=nomessage <at> entry=XIL(0x30), nosuffix=nosuffix <at> entry=XIL(0), must_suffix=must_suffix <at> entry=XIL(0x30)) at lread.c:1616
#23 0x0000555555702881 in Fautoload_do_load (fundef=XIL(0x55555677e753), funname=XIL(0xbc9bd0), macro_only=XIL(0)) at eval.c:2308
#24 0x0000555555702af2 in Ffuncall (nargs=4, args=0x7fffffff9e90) at lisp.h:1002
#25 0x0000555555702d04 in call3 (fn=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>) at eval.c:2910
#26 0x00005555556b8d76 in Fexpand_file_name (name=XIL(0x5555568573e4), default_directory=<optimized out>) at fileio.c:905
#27 0x000055555572ab71 in readevalloop
(readcharfun=XIL(0x7770), infile0=0x7fffffffa0d0, sourcename=XIL(0x5555568573e4), printflag=false, unibyte=XIL(0), readfun=XIL(0), start=<optimized out>, end=XIL(0)) at lisp.h:1002
#28 0x000055555572bbb1 in Fload
(file=<optimized out>, noerror=XIL(0), nomessage=XIL(0x30), nosuffix=<optimized out>, must_suffix=<optimized out>) at lisp.h:1002
#29 0x000055555572be5a in save_match_data_load
(file=XIL(0x555556847f74), noerror=noerror <at> entry=XIL(0), nomessage=nomessage <at> entry=XIL(0x30), nosuffix=nosuffix <at> entry=XIL(0), must_suffix=must_suffix <at> entry=XIL(0x30)) at lread.c:1616
#30 0x0000555555702881 in Fautoload_do_load (fundef=XIL(0x55555677e753), funname=XIL(0xbc9bd0), macro_only=XIL(0)) at eval.c:2308
#31 0x0000555555702af2 in Ffuncall (nargs=5, args=0x7fffffffa2a8) at lisp.h:1002
#32 0x000055555573df98 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
#33 0x0000555555702b37 in Ffuncall (nargs=4, args=0x7fffffffa580) at eval.c:3052
#34 0x00005555557049f8 in Fapply (nargs=2, args=0x7fffffffa610) at eval.c:2666
#35 0x00005555557052fc in eval_sub (form=<optimized out>) at lisp.h:731
#36 0x0000555555705ca5 in Fprogn (body=XIL(0)) at eval.c:471
#37 funcall_lambda (fun=<optimized out>, nargs=4, arg_vector=0x7fffffffa7d0) at eval.c:3313
#38 0x0000555555702b37 in Ffuncall (nargs=5, args=0x7fffffffa7c8) at eval.c:3052
#39 0x000055555573df98 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
#40 0x0000555555702b37 in Ffuncall (nargs=2, args=0x7fffffffaaa0) at eval.c:3052
#41 0x0000555555702caa in call1 (fn=<optimized out>, arg1=arg1 <at> entry=XIL(0x555555caf184)) at eval.c:2896
#42 0x00005555555d9b17 in decode_mode_spec (string=<synthetic pointer>, field_width=1, c=<optimized out>, w=<optimized out>)
at xdisp.c:26947
#43 display_mode_element
(it=<optimized out>, depth=<optimized out>, field_width=<optimized out>, precision=<optimized out>, elt=<optimized out>, props=XIL(0), risky=<optimized out>) at xdisp.c:25855
#44 0x00005555555d98b2 in display_mode_element
(it=0x7fffffffadd0, depth=3, field_width=0, precision=-5, elt=<optimized out>, props=XIL(0), risky=<optimized out>) at lisp.h:719
#45 0x00005555555d98b2 in display_mode_element
(it=0x7fffffffadd0, depth=1, field_width=0, precision=0, elt=<optimized out>, props=XIL(0), risky=<optimized out>) at lisp.h:719
#46 0x00005555555db1a4 in display_mode_line (w=w <at> entry=0x55555602f120, face_id=<optimized out>, format=XIL(0x7ffff1c35e2b))
at lisp.h:1002
#47 0x00005555555db3ce in display_mode_lines (w=w <at> entry=0x55555602f120) at xdisp.c:25415
#48 0x00005555555db613 in redisplay_mode_lines (window=XIL(0x55555602f125), force=force <at> entry=false) at xdisp.c:25351
#49 0x00005555555e68fb in echo_area_display (update_frame_p=<optimized out>) at xdisp.c:12289
#50 0x00005555555e6a59 in message3_nolog (m=<optimized out>) at xdisp.c:11232
#51 0x00005555555e6cc8 in message3 (m=m <at> entry=XIL(0x555556034f54)) at xdisp.c:11162
#52 0x00005555556f9df0 in Fmessage (args=0x7fffffffc350, nargs=<optimized out>) at editfns.c:2875
#53 Fmessage (nargs=<optimized out>, args=0x7fffffffc350) at editfns.c:2843
#54 0x0000555555702bfb in Ffuncall (nargs=3, args=0x7fffffffc348) at eval.c:3036
#55 0x000055555573df98 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
#56 0x0000555555702b37 in Ffuncall (nargs=1, args=0x7fffffffc690) at eval.c:3052
#57 0x000055555573df98 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
#58 0x0000555555702b37 in Ffuncall (nargs=2, args=0x7fffffffce68) at eval.c:3052
#59 0x000055555573df98 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
#60 0x0000555555702b37 in Ffuncall (nargs=1, args=0x7fffffffd730) at eval.c:3052
#61 0x000055555573df98 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
#62 0x0000555555705e5f in apply_lambda (fun=XIL(0x7ffff1bc6d85), args=<optimized out>, count=4) at eval.c:3185
#63 0x0000555555704ee3 in eval_sub (form=<optimized out>) at eval.c:2588
#64 0x0000555555706b09 in Feval (form=XIL(0x7ffff20f0e2b), lexical=<optimized out>) at eval.c:2340
#65 0x0000555555701bd7 in internal_condition_case
(bfun=bfun <at> entry=0x555555687050 <top_level_2>, handlers=handlers <at> entry=XIL(0x90), hfun=hfun <at> entry=0x55555568c860 <cmd_error>)
at eval.c:1475
#66 0x0000555555687cc6 in top_level_1 (ignore=ignore <at> entry=XIL(0)) at keyboard.c:1111
#67 0x00005555557040d3 in internal_catch (tag=tag <at> entry=XIL(0xe4c0), func=func <at> entry=0x555555687ca0 <top_level_1>, arg=arg <at> entry=XIL(0))
at eval.c:1198
#68 0x0000555555686fd8 in command_loop () at lisp.h:1002
#69 0x000055555568c476 in recursive_edit_1 () at keyboard.c:720
#70 0x000055555568c7a2 in Frecursive_edit () at keyboard.c:789
#71 0x00005555555a2cda in main (argc=2, argv=<optimized out>) at emacs.c:2297
Lisp Backtrace:
"tramp-archive-file-name-handler" (0xffff92c8)
"tramp-archive-file-name-handler" (0xffff96b8)
"tramp-archive-file-name-handler" (0xffff9aa8)
"tramp-archive-file-name-handler" (0xffff9e98)
"tramp-archive-file-name-handler" (0xffffa2b0)
"file-remote-p" (0xffffa588)
"apply" (0xffffa610)
"tramp-archive-autoload-file-name-handler" (0xffffa7d0)
"file-remote-p" (0xffffaaa8)
"message" (0xffffc350)
"display-startup-echo-area-message" (0xffffc698)
"command-line-1" (0xffffce70)
"command-line" (0xffffd738)
"normal-top-level" (0xffffdc00)
(gdb)
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48476
; Package
emacs
.
(Mon, 17 May 2021 15:53:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 48476 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
Hi Lars,
>>> My emacs get stuck with 100% cpu when started from a directory ending with
>>> ".tar".
Sure, this is the Tramp archive handler. But it shall be invoked only
when the file name ends with ".tar/" - see the trailing slash.
>>> For example, the following commands trigger the error:
>>> - mkdir test.tar
>>> - cd test.tar
>>> - emacs
Yes. But is this a real scenario?
> I have not tried to debug further, but this strace seems to indicate
> that this might be Tramp-related, so I've added Michael to the CCs --
> perhaps it'll be immediately obvious to him what the problem is. :-)
Hmm, Tramp shall return with an error message (possibly) or give
up. Will investigate.
Anyway, setting tramp-archive-enabled to nil should mitigate the
problem.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48476
; Package
emacs
.
(Mon, 17 May 2021 16:04:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 48476 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
Hi Robert,
> I have a backtrace from gdb that might shed some light.
>
> Michael, this is emacs signalling an error for a recursive load,
> apparently forever.
Ahh, thanks. This gives me some ideas for check.
> Robert
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48476
; Package
emacs
.
(Wed, 19 May 2021 14:23:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 48476 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Michael Albinus <michael.albinus <at> gmx.de> writes:
Hi,
>> Michael, this is emacs signalling an error for a recursive load,
>> apparently forever.
>
> Ahh, thanks. This gives me some ideas for check.
The appended patch should fix it. It is towards the emacs-27
branch. Although there won't be a Tramp 27.3 in the future, Debian (and
other distributions) might patch its distributed Emacs 27.2.
>> Robert
Best regards, Michael.
[Message part 2 (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48476
; Package
emacs
.
(Thu, 20 May 2021 07:45:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 48476 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 19 May 2021 16:22:10 +0200, Michael Albinus <michael.albinus <at> gmx.de> said:
Michael> Michael Albinus <michael.albinus <at> gmx.de> writes:
Michael> Hi,
>>> Michael, this is emacs signalling an error for a recursive load,
>>> apparently forever.
>>
>> Ahh, thanks. This gives me some ideas for check.
Michael> The appended patch should fix it. It is towards the emacs-27
Michael> branch. Although there won't be a Tramp 27.3 in the future, Debian (and
Michael> other distributions) might patch its distributed Emacs 27.2.
emacs-27 is still looping with that patch:
openat(AT_FDCWD, "/home/rpluim/repos/emacs-27/lisp/net/tramp-archive.elc", O_RDONLY|O_CLOEXEC) = 14
openat(AT_FDCWD, "/home/rpluim/repos/emacs-27/lisp/net/tramp-archive.elc", O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/home/rpluim/repos/emacs-27/lisp/net/tramp-archive.elc", O_RDONLY|O_CLOEXEC) = 16
openat(AT_FDCWD, "/home/rpluim/repos/emacs-27/lisp/net/tramp-archive.elc", O_RDONLY|O_CLOEXEC) = 17
openat(AT_FDCWD, "/home/rpluim/repos/emacs-27/lisp/net/tramp-archive.elc", O_RDONLY|O_CLOEXEC) = 18
openat(AT_FDCWD, "/home/rpluim/repos/emacs-27/lisp/net/tramp-archive.elc", O_RDONLY|O_CLOEXEC) = 14
Iʼve not trapped it reliably in gdb yet. master is the same
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48476
; Package
emacs
.
(Thu, 20 May 2021 09:25:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 48476 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
Hi Robert,
> Michael> The appended patch should fix it. It is towards the emacs-27
> Michael> branch. Although there won't be a Tramp 27.3 in the future, Debian (and
> Michael> other distributions) might patch its distributed Emacs 27.2.
>
> emacs-27 is still looping with that patch:
Since the changes are in autoloaded functions, you must regenerate
loaddefs.el, and it must be dumped into Emacs. During my tests, I have
always applied
# rm lisp/loaddefs.el ; make
> Robert
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48476
; Package
emacs
.
(Thu, 20 May 2021 12:54:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 48476 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 20 May 2021 11:24:35 +0200, Michael Albinus <michael.albinus <at> gmx.de> said:
Michael> Robert Pluim <rpluim <at> gmail.com> writes:
Michael> Hi Robert,
Michael> The appended patch should fix it. It is towards the emacs-27
Michael> branch. Although there won't be a Tramp 27.3 in the future, Debian (and
Michael> other distributions) might patch its distributed Emacs 27.2.
>>
>> emacs-27 is still looping with that patch:
Michael> Since the changes are in autoloaded functions, you must regenerate
Michael> loaddefs.el, and it must be dumped into Emacs. During my tests, I have
Michael> always applied
Michael> # rm lisp/loaddefs.el ; make
Thanks for that. It works for me now with emacs-27 (but not on master).
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48476
; Package
emacs
.
(Thu, 20 May 2021 13:07:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 48476 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
> Thanks for that. It works for me now with emacs-27 (but not on master).
Thanks for the feedback. My patch is dedicated to the emacs-27 branch
only; once I get confirmation from Rob or Thomas, I'll push it, and I'll
prepare a similar patch for master.
One step after the other.
> Robert
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48476
; Package
emacs
.
(Thu, 20 May 2021 13:34:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 48476 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 20 May 2021 15:05:51 +0200, Michael Albinus <michael.albinus <at> gmx.de> said:
Michael> Robert Pluim <rpluim <at> gmail.com> writes:
>> Thanks for that. It works for me now with emacs-27 (but not on master).
Michael> Thanks for the feedback. My patch is dedicated to the emacs-27 branch
Michael> only; once I get confirmation from Rob or Thomas, I'll push it, and I'll
Michael> prepare a similar patch for master.
Michael> One step after the other.
No, no, no: I rush ahead testing other stuff so that the person who
knows how the code works (you) doesnʼt have to :-)
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48476
; Package
emacs
.
(Sun, 23 May 2021 11:44:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 48476 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
Hi Robert,
>> Thanks for that. It works for me now with emacs-27 (but not on master).
>
> Thanks for the feedback. My patch is dedicated to the emacs-27 branch
> only; once I get confirmation from Rob or Thomas, I'll push it, and I'll
> prepare a similar patch for master.
>
> One step after the other.
The latest commit shall work in master branch.
>> Robert
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48476
; Package
emacs
.
(Tue, 25 May 2021 08:12:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 48476 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Sun, 23 May 2021 13:42:32 +0200, Michael Albinus <michael.albinus <at> gmx.de> said:
Michael> Michael Albinus <michael.albinus <at> gmx.de> writes:
Michael> Hi Robert,
>>> Thanks for that. It works for me now with emacs-27 (but not on master).
>>
>> Thanks for the feedback. My patch is dedicated to the emacs-27 branch
>> only; once I get confirmation from Rob or Thomas, I'll push it, and I'll
>> prepare a similar patch for master.
>>
>> One step after the other.
Michael> The latest commit shall work in master branch.
Confirmed. Thanks Michael.
Robert
--
Reply sent
to
Michael Albinus <michael.albinus <at> gmx.de>
:
You have taken responsibility.
(Tue, 25 May 2021 11:05:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Rob Browning <rlb <at> defaultvalue.org>
:
bug acknowledged by developer.
(Tue, 25 May 2021 11:05:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 48476-done <at> debbugs.gnu.org (full text, mbox):
Version 28.1
Hi Robert,
Robert Pluim <rpluim <at> gmail.com> writes:
> Michael> Michael Albinus <michael.albinus <at> gmx.de> writes:
> Michael> Hi Robert,
>
> >>> Thanks for that. It works for me now with emacs-27 (but not on master).
> >>
> >> Thanks for the feedback. My patch is dedicated to the emacs-27 branch
> >> only; once I get confirmation from Rob or Thomas, I'll push it, and I'll
> >> prepare a similar patch for master.
> >>
> >> One step after the other.
>
> Michael> The latest commit shall work in master branch.
>
> Confirmed. Thanks Michael.
Thanks for the confirmation. Nobody else has commented, so I'm closing bug#48476.
> Robert
Best regards, Michael.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 22 Jun 2021 11:24:08 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
Michael Albinus <michael.albinus <at> gmx.de>
to
control <at> debbugs.gnu.org
.
(Sun, 15 Jan 2023 18:29:01 GMT)
Full text and
rfc822 format available.
Forcibly Merged 48476 60796.
Request was from
Michael Albinus <michael.albinus <at> gmx.de>
to
control <at> debbugs.gnu.org
.
(Sun, 15 Jan 2023 18:30:01 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
60796 <at> debbugs.gnu.org and Casey Connor <emacsbugs <at> caseyconnor.org>
Request was from
Michael Albinus <michael.albinus <at> gmx.de>
to
control <at> debbugs.gnu.org
.
(Sun, 15 Jan 2023 18:31:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 13 Feb 2023 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 45 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.