* 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 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
[parent not found: <87wnrx9wl6.fsf@gmx.de>]
* 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
* 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
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 external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.