* bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"
[not found] <162115594747.5027.12325478473634405780.reportbug@ant64>
@ 2021-05-16 22:49 ` Rob Browning
2021-05-17 14:42 ` Lars Ingebrigtsen
0 siblings, 1 reply; 14+ messages in thread
From: Rob Browning @ 2021-05-16 22:49 UTC (permalink / raw)
To: 48476; +Cc: 988581-forwarded, Thomas Lundqvist, 988581
[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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"
2021-05-16 22:49 ` 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
@ 2021-05-17 14:42 ` Lars Ingebrigtsen
2021-05-17 15:24 ` Robert Pluim
2021-05-17 15:51 ` Michael Albinus
0 siblings, 2 replies; 14+ messages in thread
From: Lars Ingebrigtsen @ 2021-05-17 14:42 UTC (permalink / raw)
To: Rob Browning
Cc: 48476, 988581-forwarded, Michael Albinus, Thomas Lundqvist,
988581
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"
2021-05-17 14:42 ` Lars Ingebrigtsen
@ 2021-05-17 15:24 ` Robert Pluim
2021-05-17 16:03 ` Michael Albinus
[not found] ` <87wnrx9wl6.fsf@gmx.de>
2021-05-17 15:51 ` Michael Albinus
1 sibling, 2 replies; 14+ messages in thread
From: Robert Pluim @ 2021-05-17 15:24 UTC (permalink / raw)
To: Lars Ingebrigtsen
Cc: 988581-forwarded, Thomas Lundqvist, 988581, Michael Albinus,
48476, Rob Browning
>>>>> 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
--
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"
2021-05-17 14:42 ` Lars Ingebrigtsen
2021-05-17 15:24 ` Robert Pluim
@ 2021-05-17 15:51 ` Michael Albinus
1 sibling, 0 replies; 14+ messages in thread
From: Michael Albinus @ 2021-05-17 15:51 UTC (permalink / raw)
To: Lars Ingebrigtsen
Cc: 988581-forwarded, 48476, Thomas Lundqvist, Rob Browning, 988581
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"
2021-05-17 15:24 ` Robert Pluim
@ 2021-05-17 16:03 ` Michael Albinus
[not found] ` <87wnrx9wl6.fsf@gmx.de>
1 sibling, 0 replies; 14+ messages in thread
From: Michael Albinus @ 2021-05-17 16:03 UTC (permalink / raw)
To: Robert Pluim
Cc: 988581-forwarded, Thomas Lundqvist, 988581, Lars Ingebrigtsen,
48476, Rob Browning
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"
[not found] ` <87wnrx9wl6.fsf@gmx.de>
@ 2021-05-19 14:22 ` Michael Albinus
2021-05-20 7:44 ` Robert Pluim
0 siblings, 1 reply; 14+ messages in thread
From: Michael Albinus @ 2021-05-19 14:22 UTC (permalink / raw)
To: Robert Pluim
Cc: 988581-forwarded, Thomas Lundqvist, 988581, Lars Ingebrigtsen,
48476, Rob Browning
[-- 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)))
^ permalink raw reply related [flat|nested] 14+ messages in thread
* bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"
2021-05-19 14:22 ` Michael Albinus
@ 2021-05-20 7:44 ` Robert Pluim
2021-05-20 9:24 ` Michael Albinus
0 siblings, 1 reply; 14+ messages in thread
From: Robert Pluim @ 2021-05-20 7:44 UTC (permalink / raw)
To: Michael Albinus
Cc: 988581-forwarded, Thomas Lundqvist, 988581, Lars Ingebrigtsen,
48476, Rob Browning
>>>>> 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
--
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"
2021-05-20 7:44 ` Robert Pluim
@ 2021-05-20 9:24 ` Michael Albinus
2021-05-20 12:53 ` Robert Pluim
0 siblings, 1 reply; 14+ messages in thread
From: Michael Albinus @ 2021-05-20 9:24 UTC (permalink / raw)
To: Robert Pluim
Cc: 988581-forwarded, Thomas Lundqvist, 988581, Lars Ingebrigtsen,
48476, Rob Browning
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"
2021-05-20 9:24 ` Michael Albinus
@ 2021-05-20 12:53 ` Robert Pluim
2021-05-20 13:05 ` Michael Albinus
0 siblings, 1 reply; 14+ messages in thread
From: Robert Pluim @ 2021-05-20 12:53 UTC (permalink / raw)
To: Michael Albinus
Cc: 988581-forwarded, Thomas Lundqvist, 988581, Lars Ingebrigtsen,
48476, Rob Browning
>>>>> 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
--
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"
2021-05-20 12:53 ` Robert Pluim
@ 2021-05-20 13:05 ` Michael Albinus
2021-05-20 13:33 ` Robert Pluim
2021-05-23 11:42 ` Michael Albinus
0 siblings, 2 replies; 14+ messages in thread
From: Michael Albinus @ 2021-05-20 13:05 UTC (permalink / raw)
To: Robert Pluim
Cc: 988581-forwarded, Thomas Lundqvist, 988581, Lars Ingebrigtsen,
48476, Rob Browning
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"
2021-05-20 13:05 ` Michael Albinus
@ 2021-05-20 13:33 ` Robert Pluim
2021-05-23 11:42 ` Michael Albinus
1 sibling, 0 replies; 14+ messages in thread
From: Robert Pluim @ 2021-05-20 13:33 UTC (permalink / raw)
To: Michael Albinus
Cc: 988581-forwarded, Thomas Lundqvist, 988581, Lars Ingebrigtsen,
48476, Rob Browning
>>>>> 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
--
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"
2021-05-20 13:05 ` Michael Albinus
2021-05-20 13:33 ` Robert Pluim
@ 2021-05-23 11:42 ` Michael Albinus
2021-05-25 8:11 ` Robert Pluim
1 sibling, 1 reply; 14+ messages in thread
From: Michael Albinus @ 2021-05-23 11:42 UTC (permalink / raw)
To: Robert Pluim
Cc: 988581-forwarded, Thomas Lundqvist, 988581, Lars Ingebrigtsen,
48476, Rob Browning
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"
2021-05-23 11:42 ` Michael Albinus
@ 2021-05-25 8:11 ` Robert Pluim
2021-05-25 11:04 ` Michael Albinus
0 siblings, 1 reply; 14+ messages in thread
From: Robert Pluim @ 2021-05-25 8:11 UTC (permalink / raw)
To: Michael Albinus
Cc: 988581-forwarded, Thomas Lundqvist, 988581, Lars Ingebrigtsen,
48476, Rob Browning
>>>>> 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
--
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#48476: Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"
2021-05-25 8:11 ` Robert Pluim
@ 2021-05-25 11:04 ` Michael Albinus
0 siblings, 0 replies; 14+ messages in thread
From: Michael Albinus @ 2021-05-25 11:04 UTC (permalink / raw)
To: Robert Pluim
Cc: 988581-forwarded, Thomas Lundqvist, 988581, Lars Ingebrigtsen,
48476-done, Rob Browning
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-05-25 11:04 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <162115594747.5027.12325478473634405780.reportbug@ant64>
2021-05-16 22:49 ` 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
2021-05-17 14:42 ` Lars Ingebrigtsen
2021-05-17 15:24 ` Robert Pluim
2021-05-17 16:03 ` Michael Albinus
[not found] ` <87wnrx9wl6.fsf@gmx.de>
2021-05-19 14:22 ` Michael Albinus
2021-05-20 7:44 ` Robert Pluim
2021-05-20 9:24 ` Michael Albinus
2021-05-20 12:53 ` Robert Pluim
2021-05-20 13:05 ` Michael Albinus
2021-05-20 13:33 ` Robert Pluim
2021-05-23 11:42 ` Michael Albinus
2021-05-25 8:11 ` Robert Pluim
2021-05-25 11:04 ` Michael Albinus
2021-05-17 15:51 ` Michael Albinus
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).