Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#988581: emacs-gtk: Emacs hangs with 100% cpu if started within a current directory that has a name ending with ".tar"
10 views
Skip to first unread message
Thomas Lundqvist
May 16, 2021, 5:20:03 AM5/16/21
to
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
-- System Information:
Debian Release: 11.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-6-amd64 (SMP w/14 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages emacs-gtk depends on:
ii emacs-bin-common 1:27.1+1-3.1
ii emacs-common 1:27.1+1-3.1
ii libacl1 2.2.53-10
ii libasound2 1.2.4-1.1
ii libc6 2.31-11
ii libcairo2 1.16.0-5
ii libdbus-1-3 1.12.20-2
ii libfontconfig1 2.13.1-4.2
ii libfreetype6 2.10.4+dfsg-1
ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1
ii libgif7 5.1.9-2
ii libglib2.0-0 2.66.8-1
ii libgmp10 2:6.2.1+dfsg-1
ii libgnutls30 3.7.1-3
ii libgpm2 1.20.7-8
ii libgtk-3-0 3.24.24-4
ii libharfbuzz0b 2.7.4-1
ii libice6 2:1.0.10-1
ii libjansson4 2.13.1-1.1
ii libjpeg62-turbo 1:2.0.6-4
ii liblcms2-2 2.12~rc1-2
ii libm17n-0 1.8.0-2
ii libotf0 0.9.13-7
ii libpango-1.0-0 1.46.2-3
ii libpng16-16 1.6.37-3
ii librsvg2-2 2.50.3+dfsg-1
ii libselinux1 3.1-3
ii libsm6 2:1.2.3-1
ii libsystemd0 247.3-5
ii libtiff5 4.2.0-1
ii libtinfo6 6.2+20201114-2
ii libx11-6 2:1.7.0-2
ii libxext6 2:1.3.3-1.1
ii libxfixes3 1:5.0.3-2
ii libxml2 2.9.10+dfsg-6.6
ii libxrender1 1:0.9.10-1
ii zlib1g 1:1.2.11.dfsg-2
emacs-gtk recommends no packages.
Versions of packages emacs-gtk suggests:
pn emacs-common-non-dfsg <none>
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
-- System Information:
Debian Release: 11.0
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-6-amd64 (SMP w/14 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages emacs-gtk depends on:
ii emacs-bin-common 1:27.1+1-3.1
ii emacs-common 1:27.1+1-3.1
ii libacl1 2.2.53-10
ii libasound2 1.2.4-1.1
ii libc6 2.31-11
ii libcairo2 1.16.0-5
ii libdbus-1-3 1.12.20-2
ii libfontconfig1 2.13.1-4.2
ii libfreetype6 2.10.4+dfsg-1
ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1
ii libgif7 5.1.9-2
ii libglib2.0-0 2.66.8-1
ii libgmp10 2:6.2.1+dfsg-1
ii libgnutls30 3.7.1-3
ii libgpm2 1.20.7-8
ii libgtk-3-0 3.24.24-4
ii libharfbuzz0b 2.7.4-1
ii libice6 2:1.0.10-1
ii libjansson4 2.13.1-1.1
ii libjpeg62-turbo 1:2.0.6-4
ii liblcms2-2 2.12~rc1-2
ii libm17n-0 1.8.0-2
ii libotf0 0.9.13-7
ii libpango-1.0-0 1.46.2-3
ii libpng16-16 1.6.37-3
ii librsvg2-2 2.50.3+dfsg-1
ii libselinux1 3.1-3
ii libsm6 2:1.2.3-1
ii libsystemd0 247.3-5
ii libtiff5 4.2.0-1
ii libtinfo6 6.2+20201114-2
ii libx11-6 2:1.7.0-2
ii libxext6 2:1.3.3-1.1
ii libxfixes3 1:5.0.3-2
ii libxml2 2.9.10+dfsg-6.6
ii libxrender1 1:0.9.10-1
ii zlib1g 1:1.2.11.dfsg-2
emacs-gtk recommends no packages.
Versions of packages emacs-gtk suggests:
pn emacs-common-non-dfsg <none>
Rob Browning
May 16, 2021, 7:00:03 PM5/16/21
to
[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 <tlund...@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
--
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
Lars Ingebrigtsen
May 17, 2021, 11:20:03 AM5/17/21
to
Rob Browning <r...@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
>> 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
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
Robert Pluim
May 17, 2021, 11:30:03 AM5/17/21
to
>>>>> On Mon, 17 May 2021 16:42:33 +0200, Lars Ingebrigtsen <la...@gnus.org> said:
Lars> Rob Browning <r...@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
--
Lars> Rob Browning <r...@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> 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
--
Michael Albinus
May 17, 2021, 12:00:03 PM5/17/21
to
Lars Ingebrigtsen <la...@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.
Hi Lars,
>>> My emacs get stuck with 100% cpu when started from a directory ending with
>>> ".tar".
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
> 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. :-)
up. Will investigate.
Anyway, setting tramp-archive-enabled to nil should mitigate the
problem.
Best regards, Michael.
Michael Albinus
May 17, 2021, 12:10:03 PM5/17/21
to
Robert Pluim <rpl...@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.
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.
> Robert
Best regards, Michael.
Michael Albinus
May 19, 2021, 10:30:03 AM5/19/21
to
Michael Albinus <michael...@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.
Hi,
>> Michael, this is emacs signalling an error for a recursive load,
>> apparently forever.
>
> Ahh, thanks. This gives me some ideas for check.
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.
Robert Pluim
May 20, 2021, 3:50:03 AM5/20/21
to
>>>>> On Wed, 19 May 2021 16:22:10 +0200, Michael Albinus <michael...@gmx.de> said:
Michael> Michael Albinus <michael...@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
--
Michael> Michael Albinus <michael...@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> 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
--
Michael Albinus
May 20, 2021, 5:30:04 AM5/20/21
to
> 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
> 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:
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.
Robert Pluim
May 20, 2021, 9:00:04 AM5/20/21
to
>>>>> On Thu, 20 May 2021 11:24:35 +0200, Michael Albinus <michael...@gmx.de> said:
Michael> Robert Pluim <rpl...@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
--
Michael> Robert Pluim <rpl...@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> 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
--
Michael Albinus
May 20, 2021, 9:10:04 AM5/20/21
to
Robert Pluim <rpl...@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
> Thanks for that. It works for me now with emacs-27 (but not on master).
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.
Robert Pluim
May 20, 2021, 9:40:03 AM5/20/21
to
>>>>> On Thu, 20 May 2021 15:05:51 +0200, Michael Albinus <michael...@gmx.de> said:
Michael> Robert Pluim <rpl...@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
--
Michael> Robert Pluim <rpl...@gmail.com> writes:
>> Thanks for that. It works for me now with emacs-27 (but not on master).
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
--
Michael Albinus
May 23, 2021, 7:50:04 AM5/23/21
to
Michael Albinus <michael...@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.
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.
>> Robert
Best regards, Michael.
Robert Pluim
May 25, 2021, 4:20:03 AM5/25/21
to
>>>>> On Sun, 23 May 2021 13:42:32 +0200, Michael Albinus <michael...@gmx.de> said:
Michael> Michael Albinus <michael...@gmx.de> writes:
Michael> Hi Robert,
Michael> Michael Albinus <michael...@gmx.de> 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.
Confirmed. Thanks Michael.
Robert
--
Michael Albinus
May 25, 2021, 7:10:03 AM5/25/21
to
Version 28.1
Hi Robert,
Robert Pluim <rpl...@gmail.com> writes:
> Michael> Michael Albinus <michael...@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.
Hi Robert,
Robert Pluim <rpl...@gmail.com> writes:
> Michael> Michael Albinus <michael...@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
Best regards, Michael.
Zakari Bikienga
May 14, 2023, 7:30:10 AM5/14/23
to
Lieber Freund,
Wie geht es dir? Ich weiß, dass meine Botschaft Sie überraschen wird, aber alles, was hier niedergeschrieben wird, ist die Wahrheit. Wir arbeiten im Rahmen der UN und der EU daran, alle Opfer von Cyberbetrug auf der ganzen Welt zu entschädigen. Die EU/UN hat sich 2012 mit der Cybercrime-Fundraising-Organisation zusammengetan, um alle Opfer von Cyberbetrug zu entschädigen. Die Auswahl erfolgt nur nach dem Zufallsprinzip, sodass Sie das Glück haben, kontaktiert zu werden, da Ihre detaillierte E-Mail-Adresse in unserem System angezeigt wird. Gerne geben wir Ihnen weitere Einzelheiten zu Ihrer positiven Antwort bekannt, damit Sie Ihren eigenen Anteil erhalten können. Sie können mir jedoch bei Bedarf Fragen stellen. Wir freuen uns, bald von Ihnen zu hören.
Grüße,
Fatima William.
Wie geht es dir? Ich weiß, dass meine Botschaft Sie überraschen wird, aber alles, was hier niedergeschrieben wird, ist die Wahrheit. Wir arbeiten im Rahmen der UN und der EU daran, alle Opfer von Cyberbetrug auf der ganzen Welt zu entschädigen. Die EU/UN hat sich 2012 mit der Cybercrime-Fundraising-Organisation zusammengetan, um alle Opfer von Cyberbetrug zu entschädigen. Die Auswahl erfolgt nur nach dem Zufallsprinzip, sodass Sie das Glück haben, kontaktiert zu werden, da Ihre detaillierte E-Mail-Adresse in unserem System angezeigt wird. Gerne geben wir Ihnen weitere Einzelheiten zu Ihrer positiven Antwort bekannt, damit Sie Ihren eigenen Anteil erhalten können. Sie können mir jedoch bei Bedarf Fragen stellen. Wir freuen uns, bald von Ihnen zu hören.
Grüße,
Fatima William.
0 new messages