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

Package: emacs;

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.

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: Rob Browning <rlb <at> defaultvalue.org>
To: bug-gnu-emacs <at> gnu.org
Cc: 988581-forwarded <at> bugs.debian.org, Thomas Lundqvist <tlundqvist <at> acm.org>,
 988581 <at> bugs.debian.org
Subject: Re: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started
 within a current directory that has a name ending with ".tar"
Date: Sun, 16 May 2021 17:49:25 -0500
[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):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Rob Browning <rlb <at> defaultvalue.org>
Cc: Michael Albinus <michael.albinus <at> gmx.de>, 988581-forwarded <at> bugs.debian.org,
 48476 <at> debbugs.gnu.org, Thomas Lundqvist <tlundqvist <at> acm.org>,
 988581 <at> bugs.debian.org
Subject: Re: bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if
 started within a current directory that has a name ending with ".tar"
Date: Mon, 17 May 2021 16:42:33 +0200
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):

From: Robert Pluim <rpluim <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 988581-forwarded <at> bugs.debian.org, Thomas Lundqvist <tlundqvist <at> acm.org>,
 988581 <at> bugs.debian.org, Michael Albinus <michael.albinus <at> gmx.de>,
 48476 <at> debbugs.gnu.org, Rob Browning <rlb <at> defaultvalue.org>
Subject: Re: bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if
 started within a current directory that has a name ending with ".tar"
Date: Mon, 17 May 2021 17:24:51 +0200
>>>>> 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):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 988581-forwarded <at> bugs.debian.org, 48476 <at> debbugs.gnu.org,
 Thomas Lundqvist <tlundqvist <at> acm.org>, Rob Browning <rlb <at> defaultvalue.org>,
 988581 <at> bugs.debian.org
Subject: Re: bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if
 started within a current directory that has a name ending with ".tar"
Date: Mon, 17 May 2021 17:51:45 +0200
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):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 988581-forwarded <at> bugs.debian.org, Thomas Lundqvist <tlundqvist <at> acm.org>,
 988581 <at> bugs.debian.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 48476 <at> debbugs.gnu.org, Rob Browning <rlb <at> defaultvalue.org>
Subject: Re: bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if
 started within a current directory that has a name ending with ".tar"
Date: Mon, 17 May 2021 18:03:17 +0200
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):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 988581-forwarded <at> bugs.debian.org, Thomas Lundqvist <tlundqvist <at> acm.org>,
 988581 <at> bugs.debian.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 48476 <at> debbugs.gnu.org, Rob Browning <rlb <at> defaultvalue.org>
Subject: Re: bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if
 started within a current directory that has a name ending with ".tar"
Date: Wed, 19 May 2021 16:22:10 +0200
[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):

From: Robert Pluim <rpluim <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 988581-forwarded <at> bugs.debian.org, Thomas Lundqvist <tlundqvist <at> acm.org>,
 988581 <at> bugs.debian.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 48476 <at> debbugs.gnu.org, Rob Browning <rlb <at> defaultvalue.org>
Subject: Re: bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if
 started within a current directory that has a name ending with ".tar"
Date: Thu, 20 May 2021 09:44:45 +0200
>>>>> 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):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 988581-forwarded <at> bugs.debian.org, Thomas Lundqvist <tlundqvist <at> acm.org>,
 988581 <at> bugs.debian.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 48476 <at> debbugs.gnu.org, Rob Browning <rlb <at> defaultvalue.org>
Subject: Re: bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if
 started within a current directory that has a name ending with ".tar"
Date: Thu, 20 May 2021 11:24:35 +0200
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):

From: Robert Pluim <rpluim <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 988581-forwarded <at> bugs.debian.org, Thomas Lundqvist <tlundqvist <at> acm.org>,
 988581 <at> bugs.debian.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 48476 <at> debbugs.gnu.org, Rob Browning <rlb <at> defaultvalue.org>
Subject: Re: bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if
 started within a current directory that has a name ending with ".tar"
Date: Thu, 20 May 2021 14:53:45 +0200
>>>>> 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):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 988581-forwarded <at> bugs.debian.org, Thomas Lundqvist <tlundqvist <at> acm.org>,
 988581 <at> bugs.debian.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 48476 <at> debbugs.gnu.org, Rob Browning <rlb <at> defaultvalue.org>
Subject: Re: bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if
 started within a current directory that has a name ending with ".tar"
Date: Thu, 20 May 2021 15:05:51 +0200
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):

From: Robert Pluim <rpluim <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 988581-forwarded <at> bugs.debian.org, Thomas Lundqvist <tlundqvist <at> acm.org>,
 988581 <at> bugs.debian.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 48476 <at> debbugs.gnu.org, Rob Browning <rlb <at> defaultvalue.org>
Subject: Re: bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if
 started within a current directory that has a name ending with ".tar"
Date: Thu, 20 May 2021 15:33:17 +0200
>>>>> 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):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 988581-forwarded <at> bugs.debian.org, Thomas Lundqvist <tlundqvist <at> acm.org>,
 988581 <at> bugs.debian.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 48476 <at> debbugs.gnu.org, Rob Browning <rlb <at> defaultvalue.org>
Subject: Re: bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if
 started within a current directory that has a name ending with ".tar"
Date: Sun, 23 May 2021 13:42:32 +0200
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):

From: Robert Pluim <rpluim <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 988581-forwarded <at> bugs.debian.org, Thomas Lundqvist <tlundqvist <at> acm.org>,
 988581 <at> bugs.debian.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 48476 <at> debbugs.gnu.org, Rob Browning <rlb <at> defaultvalue.org>
Subject: Re: bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if
 started within a current directory that has a name ending with ".tar"
Date: Tue, 25 May 2021 10:11:24 +0200
>>>>> 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):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 988581-forwarded <at> bugs.debian.org, Thomas Lundqvist <tlundqvist <at> acm.org>,
 988581 <at> bugs.debian.org, Lars Ingebrigtsen <larsi <at> gnus.org>,
 48476-done <at> debbugs.gnu.org, Rob Browning <rlb <at> defaultvalue.org>
Subject: Re: bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if
 started within a current directory that has a name ending with ".tar"
Date: Tue, 25 May 2021 13:04:15 +0200
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.