bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"

bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"

[Rob Browning]

[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@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

bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"

[Lars Ingebrigtsen]

Rob Browning <rlb@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

bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"

[Robert Pluim]

>>>>> On Mon, 17 May 2021 16:42:33 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Rob Browning <rlb@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@entry=XIL(0), nomessage=nomessage@entry=XIL(0x30), nosuffix=nosuffix@entry=XIL(0), must_suffix=must_suffix@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@entry=XIL(0), nomessage=nomessage@entry=XIL(0x30), nosuffix=nosuffix@entry=XIL(0), must_suffix=must_suffix@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@entry=XIL(0), nomessage=nomessage@entry=XIL(0x30), nosuffix=nosuffix@entry=XIL(0), must_suffix=must_suffix@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@entry=XIL(0), nomessage=nomessage@entry=XIL(0x30), nosuffix=nosuffix@entry=XIL(0), must_suffix=must_suffix@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@entry=XIL(0), nomessage=nomessage@entry=XIL(0x30), nosuffix=nosuffix@entry=XIL(0), must_suffix=must_suffix@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@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@entry=0x55555602f120, face_id=<optimized out>, format=XIL(0x7ffff1c35e2b))
    at lisp.h:1002
#47 0x00005555555db3ce in display_mode_lines (w=w@entry=0x55555602f120) at xdisp.c:25415
#48 0x00005555555db613 in redisplay_mode_lines (window=XIL(0x55555602f125), force=force@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@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@entry=0x555555687050 <top_level_2>, handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x55555568c860 <cmd_error>)
    at eval.c:1475
#66 0x0000555555687cc6 in top_level_1 (ignore=ignore@entry=XIL(0)) at keyboard.c:1111
#67 0x00005555557040d3 in internal_catch (tag=tag@entry=XIL(0xe4c0), func=func@entry=0x555555687ca0 <top_level_1>, arg=arg@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
-- 

bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"

[Michael Albinus]

Robert Pluim <rpluim@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.

bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"

[Michael Albinus]

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

Michael Albinus <michael.albinus@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.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1321 bytes --]

diff --git a/lisp/net/tramp-archive.el b/lisp/net/tramp-archive.el
index e690687413..a8a1851abb 100644
--- a/lisp/net/tramp-archive.el
+++ b/lisp/net/tramp-archive.el
@@ -343,8 +343,12 @@ tramp-archive-file-name-handler
 	      (tramp-archive-run-real-handler operation args)))))))

 ;;;###autoload
-(defalias
-  'tramp-archive-autoload-file-name-handler #'tramp-autoload-file-name-handler)
+(progn (defun tramp-archive-autoload-file-name-handler (operation &rest args)
+  "Load Tramp archive file name handler, and perform OPERATION."
+  (if tramp-archive-enabled
+      (let ((tramp-archive-autoload t))
+        tramp-archive-autoload ; Silence byte compiler.
+        (apply #'tramp-autoload-file-name-handler operation args)))))

 ;;;###autoload
 (progn (defun tramp-register-archive-file-name-handler ()
diff --git a/lisp/net/tramp.el b/lisp/net/tramp.el
index 570294e8b9..a81dbaaf69 100644
--- a/lisp/net/tramp.el
+++ b/lisp/net/tramp.el
@@ -2444,6 +2444,8 @@ tramp-completion-file-name-handler
   (tramp-unload-file-name-handlers)
   (if tramp-mode
       (let ((default-directory temporary-file-directory))
+        (if (bound-and-true-p tramp-archive-autoload)
+	    (load "tramp-archive" 'noerror 'nomessage))
 	(load "tramp" 'noerror 'nomessage)))
   (apply operation args)))

bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"

[Robert Pluim]

>>>>> On Wed, 19 May 2021 16:22:10 +0200, Michael Albinus <michael.albinus@gmx.de> said:

    Michael> Michael Albinus <michael.albinus@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
-- 

bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"

[Michael Albinus]

Robert Pluim <rpluim@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.

bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"

[Robert Pluim]

>>>>> On Thu, 20 May 2021 11:24:35 +0200, Michael Albinus <michael.albinus@gmx.de> said:

    Michael> Robert Pluim <rpluim@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
-- 

bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"

[Michael Albinus]

Robert Pluim <rpluim@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.

bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"

[Robert Pluim]

>>>>> On Thu, 20 May 2021 15:05:51 +0200, Michael Albinus <michael.albinus@gmx.de> said:

    Michael> Robert Pluim <rpluim@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
-- 

bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"

[Michael Albinus]

Michael Albinus <michael.albinus@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.

bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"

[Robert Pluim]

>>>>> On Sun, 23 May 2021 13:42:32 +0200, Michael Albinus <michael.albinus@gmx.de> said:

    Michael> Michael Albinus <michael.albinus@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
-- 

bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"

[Michael Albinus]

Version 28.1

Hi Robert,

Robert Pluim <rpluim@gmail.com> writes:

>     Michael> Michael Albinus <michael.albinus@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#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"

[Michael Albinus]

Lars Ingebrigtsen <larsi@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.