bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

I can't reproduce from emacs -Q using M-x find-file, but the bug happens
with Helm when using M-x helm-find-files /sudo::
Emacs freeze and then in gdb:

    Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
    0x0000555555837be7 in doprnt.part ()

In all previous emacs this worked normally, working fine here in
emacs-28.1.
This is a followup of bug #55555.

I can send more infos from gdb if you give me instructions, I tried bt
but the output is huge.

Thanks.


In GNU Emacs 28.1 (build 2, x86_64-pc-linux-gnu, Motif Version 2.3.8, cairo version 1.16.0)
 of 2022-04-20 built on IPad-S340
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: Linux Mint 20.3

Configured using:
 'configure CFLAGS=-O8 --with-mailutils --with-cairo --without-dbus
 --without-gconf --without-gsettings --with-x-toolkit=motif'

Configured features:
ACL CAIRO FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ JPEG JSON LCMS2
LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE
XIM XPM MOTIF ZLIB

Important settings:
  value of $LANG: fr_FR.UTF-8
  locale-coding-system: utf-8-unix

Major mode: İĽ

Minor modes in effect:
  global-undo-tree-mode: t
  undo-tree-mode: t
  psession-mode: t
  psession-savehist-mode: t
  global-git-gutter-mode: t
  display-time-mode: t
  winner-mode: t
  helm-epa-mode: t
  helm-descbinds-mode: t
  helm-adaptive-mode: t
  helm-mode: t
  helm-minibuffer-history-mode: t
  helm-ff-icon-mode: t
  shell-dirtrack-mode: t
  helm-popup-tip-mode: t
  async-bytecomp-package-mode: t
  dired-async-mode: t
  minibuffer-depth-indicate-mode: t
  override-global-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow emacsbug helm-command gnutls network-stream nsm mailalias
epa-mail face-remap w3m-form w3m-symbol w3m doc-view jka-compr timezone
w3m-hist w3m-fb bookmark-w3m w3m-ems w3m-favicon w3m-image tab-line
w3m-proc w3m-util emamux epa-file em-unix em-term term disp-table ehelp
em-script em-prompt em-ls em-hist em-pred em-glob em-cmpl em-dirs
esh-var em-basic em-banner em-alias esh-mode esh-toggle smerge-mode qp
sort gnus-cite mm-archive smiley mail-extr view addressbook-bookmark
mu4e-config org-mu4e mu4e-contrib mu4e-patch mu4e mu4e-org mu4e-view
gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum gnus-group
gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail mail-source utf7
netrc nnoo gnus-spec gnus-int gnus-range gnus-win mu4e-main mu4e-headers
mu4e-compose mu4e-draft mu4e-actions smtpmail sendmail mu4e-search
mu4e-lists mu4e-bookmarks mu4e-mark mu4e-message shr kinsoku svg
flow-fill hl-line mu4e-contacts mu4e-update mu4e-folders mu4e-server
mu4e-context mu4e-vars mu4e-helpers ido mu4e-meta tramp-cache
helm-firefox helm-x-files helm-for-files dired-x image-file
image-converter char-fold tramp-archive tramp-gvfs dbus markdown-mode
vc-filewise vc-rcs conf-mode ledger-config ledger-mode ledger-check
ledger-texi ledger-test ledger-sort ledger-report ledger-reconcile
ledger-occur ledger-fonts ledger-fontify ledger-state ledger-complete
ledger-schedule ledger-init ledger-xact ledger-post ledger-exec
ledger-navigate eshell esh-cmd esh-ext esh-opt esh-proc esh-io esh-arg
esh-module esh-groups esh-util ledger-context ledger-commodities
ledger-regex cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs make-mode flymake-proc flymake
project warnings sh-script smie executable bug-reference naquadah-theme
solar cal-dst holidays hol-loaddefs tv-utils osm dom yaml-mode undo-tree
diff queue rainbow-mode color psession frameset log-view pcvs-util
pcmpl-git cl-indent ffap thingatpt autocrypt-message message rmc puny
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader autocrypt-gnus gnus nnheader gnus-util
rmail rmail-loaddefs rfc2047 rfc2045 mail-utils mm-util mail-prsvr
autocrypt-mu4e autocrypt ietf-drums config-w3m git-gutter mule-util appt
diary-lib diary-loaddefs gud pcomplete-extension pcmpl-unix pcmpl-gnu
iterator pcase wdired dired-extension org-config ob-gnuplot org-crypt
net-utils time winner autotest-mode autoconf-mode woman man ediff
ediff-merg ediff-mult ediff-wind ediff-diff ediff-help ediff-init
ediff-util init-helm helm-ls-git vc-git diff-mode vc vc-dispatcher
helm-fd epa derived epg rfc6068 epg-config helm-epa helm-imenu imenu
helm-elisp-package helm-find helm-org org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-footnote org-src ob-comint org-pcomplete
org-list org-faces org-entities noutline outline org-version
ob-emacs-lisp ob-core ob-eval org-table oc-basic bibtex ol rx org-keys
oc org-compat advice org-macs org-loaddefs cal-menu calendar
cal-loaddefs helm-external isearch-light helm-descbinds helm-wikipedia
all-the-icons all-the-icons-faces data-material data-weathericons
data-octicons data-fileicons data-faicons data-alltheicons cus-edit
wid-edit helm-ipython helm-elisp helm-eval edebug backtrace find-func
python tramp-sh helm-bookmark helm-net xml helm-info bookmark pp
helm-adaptive helm-mode helm-misc helm-files image-dired image-mode exif
filenotify tramp tramp-loaddefs trampver tramp-integration files-x
tramp-compat shell pcomplete parse-time iso8601 time-date ls-lisp
helm-buffers helm-occur helm-tags helm-locate helm-grep wgrep-helm wgrep
grep compile text-property-search comint ring helm-regexp format-spec
ansi-color helm-utils helm-help helm-types helm-extensions-autoloads
helm-config helm-autoloads helm helm-global-bindings helm-easymenu
helm-core async-bytecomp helm-source helm-multi-match helm-lib
dired-async dired-aux dired dired-loaddefs async popup diminish cl-extra
help-mode mb-depth server edmacro kmacro avoid cus-load use-package
use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key easy-mmode use-package-core finder-inf
package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib info w3m-load iso-transl tooltip
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads inotify
lcms2 dynamic-setting font-render-setting cairo motif x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 1156335 407379)
 (symbols 48 48709 4)
 (strings 32 275759 47943)
 (string-bytes 1 7943008)
 (vectors 16 98153)
 (vector-slots 8 2076952 539819)
 (floats 8 3195 3218)
 (intervals 56 78637 12313)
 (buffers 992 182))
<#secure method=pgpmime mode=sign>

-- 
Thierry

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Eli Zaretskii]

> From: Thierry Volpiatto <thievol@posteo.net>
> Date: Tue, 07 Jun 2022 15:16:36 +0000
> 
> 
> I can't reproduce from emacs -Q using M-x find-file, but the bug happens
> with Helm when using M-x helm-find-files /sudo::
> Emacs freeze and then in gdb:
> 
>     Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
>     0x0000555555837be7 in doprnt.part ()
> 
> In all previous emacs this worked normally, working fine here in
> emacs-28.1.
> This is a followup of bug #55555.
> 
> I can send more infos from gdb if you give me instructions, I tried bt
> but the output is huge.

The first step is to figure out what was the immediate reason for the
segfault, and in which source line it happened.

Your build is heavily optimized, so I suggest to rebuild with the
following additional compiler options:

   -gdwarf-4 -g3

Then run Emacs under GDB, and when it crashes, type

  (gdb) thread 1
  (gdb) bt -full 5

and post the results.

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

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


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thievol@posteo.net>
>> Date: Tue, 07 Jun 2022 15:16:36 +0000
>> 
>> 
>> I can't reproduce from emacs -Q using M-x find-file, but the bug happens
>> with Helm when using M-x helm-find-files /sudo::
>> Emacs freeze and then in gdb:
>> 
>>     Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
>>     0x0000555555837be7 in doprnt.part ()
>> 
>> In all previous emacs this worked normally, working fine here in
>> emacs-28.1.
>> This is a followup of bug #55555.
>> 
>> I can send more infos from gdb if you give me instructions, I tried bt
>> but the output is huge.
>
> The first step is to figure out what was the immediate reason for the
> segfault, and in which source line it happened.
>
> Your build is heavily optimized, so I suggest to rebuild with the
> following additional compiler options:
>
>    -gdwarf-4 -g3

Can't reproduce the crash after rebuilding with these flags.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Eli Zaretskii]

> From: Thierry Volpiatto <thievol@posteo.net>
> Cc: 55832@debbugs.gnu.org
> Date: Tue, 07 Jun 2022 17:02:19 +0000
> 
> >>     Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> >>     0x0000555555837be7 in doprnt.part ()
> >> 
> >> In all previous emacs this worked normally, working fine here in
> >> emacs-28.1.
> >> This is a followup of bug #55555.
> >> 
> >> I can send more infos from gdb if you give me instructions, I tried bt
> >> but the output is huge.
> >
> > The first step is to figure out what was the immediate reason for the
> > segfault, and in which source line it happened.
> >
> > Your build is heavily optimized, so I suggest to rebuild with the
> > following additional compiler options:
> >
> >    -gdwarf-4 -g3
> 
> Can't reproduce the crash after rebuilding with these flags.

_Only_ with these flags, or with these flags _in_addition_ to the
previous ones?

What is the value of system-configuration-options in the new build?

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

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


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thievol@posteo.net>
>> Cc: 55832@debbugs.gnu.org
>> Date: Tue, 07 Jun 2022 17:02:19 +0000
>> 
>> >>     Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
>> >>     0x0000555555837be7 in doprnt.part ()
>> >> 
>> >> In all previous emacs this worked normally, working fine here in
>> >> emacs-28.1.
>> >> This is a followup of bug #55555.
>> >> 
>> >> I can send more infos from gdb if you give me instructions, I tried bt
>> >> but the output is huge.
>> >
>> > The first step is to figure out what was the immediate reason for the
>> > segfault, and in which source line it happened.
>> >
>> > Your build is heavily optimized, so I suggest to rebuild with the
>> > following additional compiler options:
>> >
>> >    -gdwarf-4 -g3
>> 
>> Can't reproduce the crash after rebuilding with these flags.
>
> _Only_ with these flags, or with these flags _in_addition_ to the
> previous ones?

Only with these flags:

./configure CFLAGS='-gdwarf-4 -g3' --with-native-compilation

 do you want I rebuild with what I use previously
+ the flags you provided?

Would be something like this:

./configure CFLAGS='-O8 -gdwarf-4 -g3' --with-native-compilation

> What is the value of system-configuration-options in the new build?

system-configuration-options
"'CFLAGS=-gdwarf-4 -g3' --with-native-compilation"

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Eli Zaretskii]

> From: Thierry Volpiatto <thievol@posteo.net>
> Cc: 55832@debbugs.gnu.org
> Date: Tue, 07 Jun 2022 18:33:35 +0000
> 
> >> > The first step is to figure out what was the immediate reason for the
> >> > segfault, and in which source line it happened.
> >> >
> >> > Your build is heavily optimized, so I suggest to rebuild with the
> >> > following additional compiler options:
> >> >
> >> >    -gdwarf-4 -g3
> >> 
> >> Can't reproduce the crash after rebuilding with these flags.
> >
> > _Only_ with these flags, or with these flags _in_addition_ to the
> > previous ones?
> 
> Only with these flags:
> 
> ./configure CFLAGS='-gdwarf-4 -g3' --with-native-compilation

That's not what I meant.  I said "with these _additional_ compiler
options".

>  do you want I rebuild with what I use previously
> + the flags you provided?

Yes.

> Would be something like this:
> 
> ./configure CFLAGS='-O8 -gdwarf-4 -g3' --with-native-compilation

Yes, please.

> > What is the value of system-configuration-options in the new build?
> 
> system-configuration-options
> "'CFLAGS=-gdwarf-4 -g3' --with-native-compilation"

This indeed shows that the -O8 switch wasn't used.

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

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


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thievol@posteo.net>
>> Date: Tue, 07 Jun 2022 15:16:36 +0000
>> 
>> 
>> I can't reproduce from emacs -Q using M-x find-file, but the bug happens
>> with Helm when using M-x helm-find-files /sudo::
>> Emacs freeze and then in gdb:
>> 
>>     Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
>>     0x0000555555837be7 in doprnt.part ()
>> 
>> In all previous emacs this worked normally, working fine here in
>> emacs-28.1.
>> This is a followup of bug #55555.
>> 
>> I can send more infos from gdb if you give me instructions, I tried bt
>> but the output is huge.
>
> The first step is to figure out what was the immediate reason for the
> segfault, and in which source line it happened.
>
> Your build is heavily optimized, so I suggest to rebuild with the
> following additional compiler options:
>
>    -gdwarf-4 -g3

I have now rebuilded with:

./configure CFLAGS='-08 -gdwarf-4 -g3' --with-native-compilation

First try with /sudo:: I couldn't reproduce, then I waited the
native-compilation fully finish and could reproduce.

When fixing other warnings this morning I saw this warning in *Warnings*
buffer:

/usr/local/share/emacs/site-lisp/helm/helm-files.el: Error: Wrong type
argument sequencep

But couldn't figure out what is this error, I have no error or warnings
when compiling and everything work fine in emacs-28, don't know if this
could be related to this crash.

> Then run Emacs under GDB, and when it crashes, type
>
>   (gdb) thread 1
>   (gdb) bt -full 5
>
> and post the results.

[...]
[Detaching after vfork from child process 229481]

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x0000555555837be7 in doprnt (buffer=0x7fffff6702c0 "", bufsize=4000, format=0x5555558af29a "Bytecode stack overflow", ap=0x7fffff670250, format_end=<optimized out>) at doprnt.c:186
186     doprnt (char *buffer, ptrdiff_t bufsize, const char *format,
(gdb) thread 1
[Switching to thread 1 (Thread 0x7ffff07ce3c0 (LWP 226687))]
#0  0x0000555555837be7 in doprnt (buffer=0x7fffff6702c0 "", bufsize=4000, format=0x5555558af29a "Bytecode stack overflow", ap=0x7fffff670250, format_end=<optimized out>) at doprnt.c:186
186     doprnt (char *buffer, ptrdiff_t bufsize, const char *format,
(gdb) bt -full 5
#0  0x0000555555837be7 in doprnt (buffer=0x7fffff6702c0 "", bufsize=4000, format=0x5555558af29a "Bytecode stack overflow", ap=0x7fffff670250, format_end=<optimized out>) at doprnt.c:186
        fmt = <optimized out>
        bufptr = <optimized out>
        tembuf = '\000' <repeats 407 times>
        size_allocated = <optimized out>
        sprintf_buffer = <optimized out>
        big_buffer = <optimized out>
        quoting_style = <optimized out>
#1  0x0000555555838a57 in doprnt (ap=0x7fffff670250, format_end=0x0, format=0x5555558af29a "Bytecode stack overflow", bufsize=<optimized out>, buffer=<optimized out>) at doprnt.c:590
        modifier_len = "\000\001\001\001\001"
        nbytes = <optimized out>
        ap_copy = {{gp_offset = 8, fp_offset = 48, overflow_arg_area = 0x7fffff671380, reg_save_area = 0x7fffff6712c0}}
#2  evxprintf
    (buf=buf@entry=0x7fffff6702b8, bufsize=bufsize@entry=0x7fffff6702b0, nonheapbuf=nonheapbuf@entry=0x7fffff6702c0 "", bufsize_max=bufsize_max@entry=2305843009213693952, format=0x5555558af29a "Bytecode stack overflow", ap=ap@entry=0x7fffff6712a0) at doprnt.c:590
        nbytes = <optimized out>
        ap_copy = {{gp_offset = 8, fp_offset = 48, overflow_arg_area = 0x7fffff671380, reg_save_area = 0x7fffff6712c0}}
#3  0x00005555557aa5f3 in vformat_string (m=<optimized out>, ap=ap@entry=0x7fffff6712a0) at eval.c:2029
        buf = '\000' <repeats 409 times>...
        size = 4000
        buffer = 0x7fffff6702c0 ""
        used = <optimized out>
        string = <optimized out>
#4  0x00005555555aac6f in verror (m=<optimized out>, ap=ap@entry=0x7fffff6712a0) at eval.c:2041
(More stack frames follow...)


-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Thierry Volpiatto <thievol@posteo.net> writes:

>     (buf=buf@entry=0x7fffff6702b8, bufsize=bufsize@entry=0x7fffff6702b0, nonheapbuf=nonheapbuf@entry=0x7fffff6702c0 "", bufsize_max=bufsize_max@entry=2305843009213693952, format=0x5555558af29a "Bytecode stack overflow", ap=ap@entry=0x7fffff6712a0) at doprnt.c:590
>         nbytes = <optimized out>
>         ap_copy = {{gp_offset = 8, fp_offset = 48, overflow_arg_area = 0x7fffff671380, reg_save_area = 0x7fffff6712c0}}
> #3  0x00005555557aa5f3 in vformat_string (m=<optimized out>, ap=ap@entry=0x7fffff6712a0) at eval.c:2029
>         buf = '\000' <repeats 409 times>...
>         size = 4000
>         buffer = 0x7fffff6702c0 ""
>         used = <optimized out>
>         string = <optimized out>
> #4  0x00005555555aac6f in verror (m=<optimized out>, ap=ap@entry=0x7fffff6712a0) at eval.c:2041
> (More stack frames follow...)

Please send the entire backtrace.  This doesn't show what Emacs was
doing when the bytecode stack overflowed.

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Eli Zaretskii]

> From: Thierry Volpiatto <thievol@posteo.net>
> Cc: 55832@debbugs.gnu.org
> Date: Tue, 07 Jun 2022 19:20:39 +0000
> 
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> 0x0000555555837be7 in doprnt (buffer=0x7fffff6702c0 "", bufsize=4000, format=0x5555558af29a "Bytecode stack overflow", ap=0x7fffff670250, format_end=<optimized out>) at doprnt.c:186
> 186     doprnt (char *buffer, ptrdiff_t bufsize, const char *format,
> (gdb) thread 1
> [Switching to thread 1 (Thread 0x7ffff07ce3c0 (LWP 226687))]
> #0  0x0000555555837be7 in doprnt (buffer=0x7fffff6702c0 "", bufsize=4000, format=0x5555558af29a "Bytecode stack overflow", ap=0x7fffff670250, format_end=<optimized out>) at doprnt.c:186
> 186     doprnt (char *buffer, ptrdiff_t bufsize, const char *format,
> (gdb) bt -full 5
> #0  0x0000555555837be7 in doprnt (buffer=0x7fffff6702c0 "", bufsize=4000, format=0x5555558af29a "Bytecode stack overflow", ap=0x7fffff670250, format_end=<optimized out>) at doprnt.c:186
>         fmt = <optimized out>
>         bufptr = <optimized out>
>         tembuf = '\000' <repeats 407 times>
>         size_allocated = <optimized out>
>         sprintf_buffer = <optimized out>
>         big_buffer = <optimized out>
>         quoting_style = <optimized out>
> #1  0x0000555555838a57 in doprnt (ap=0x7fffff670250, format_end=0x0, format=0x5555558af29a "Bytecode stack overflow", bufsize=<optimized out>, buffer=<optimized out>) at doprnt.c:590
>         modifier_len = "\000\001\001\001\001"
>         nbytes = <optimized out>
>         ap_copy = {{gp_offset = 8, fp_offset = 48, overflow_arg_area = 0x7fffff671380, reg_save_area = 0x7fffff6712c0}}
> #2  evxprintf
>     (buf=buf@entry=0x7fffff6702b8, bufsize=bufsize@entry=0x7fffff6702b0, nonheapbuf=nonheapbuf@entry=0x7fffff6702c0 "", bufsize_max=bufsize_max@entry=2305843009213693952, format=0x5555558af29a "Bytecode stack overflow", ap=ap@entry=0x7fffff6712a0) at doprnt.c:590
>         nbytes = <optimized out>
>         ap_copy = {{gp_offset = 8, fp_offset = 48, overflow_arg_area = 0x7fffff671380, reg_save_area = 0x7fffff6712c0}}

Sounds like C stack overflow trying to print a too-long variable-arg
list?  Why else would a program segfault when calling a function?

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Sounds like C stack overflow trying to print a too-long variable-arg
> list? 

If that's the problem, then perhaps this problem is fixed in Emacs 29 --
Mattias has reimplemented the printer to not be recursive (because
printing certain very deep structures will segfault Emacs versions
before 29).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Thierry Volpiatto <thievol@posteo.net>,  55832@debbugs.gnu.org
> Date: Wed, 08 Jun 2022 20:17:05 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Sounds like C stack overflow trying to print a too-long variable-arg
> > list? 
> 
> If that's the problem, then perhaps this problem is fixed in Emacs 29 --
> Mattias has reimplemented the printer to not be recursive (because
> printing certain very deep structures will segfault Emacs versions
> before 29).

The non-recursive implementation of the printer AFAIU only helps when
we need to print a deeply-recursive Lisp structure.  Here, if I'm
right, the problem is that the va_arg argument list is too long -- and
all of them are pushed onto the C stack.

So Mattias's changes could only help in this case if the complete
backtrace will show recursive calls to print_object etc.

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Sounds like C stack overflow trying to print a too-long variable-arg
>> > list? 

[...]

> So Mattias's changes could only help in this case if the complete
> backtrace will show recursive calls to print_object etc.

Oh, I didn't think there was any way to get a C stack overflow when
printing a normal list?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

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


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: Thierry Volpiatto <thievol@posteo.net>,  55832@debbugs.gnu.org
>> Date: Wed, 08 Jun 2022 20:17:05 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Sounds like C stack overflow trying to print a too-long variable-arg
>> > list? 
>> 
>> If that's the problem, then perhaps this problem is fixed in Emacs 29 --
>> Mattias has reimplemented the printer to not be recursive (because
>> printing certain very deep structures will segfault Emacs versions
>> before 29).
>
> The non-recursive implementation of the printer AFAIU only helps when
> we need to print a deeply-recursive Lisp structure.  Here, if I'm
> right, the problem is that the va_arg argument list is too long -- and
> all of them are pushed onto the C stack.
>
> So Mattias's changes could only help in this case if the complete
> backtrace will show recursive calls to print_object etc.

Let me know what you want exactly for the complete backtrace.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Eli Zaretskii]

> From: Thierry Volpiatto <thievol@posteo.net>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 55832@debbugs.gnu.org
> Date: Thu, 09 Jun 2022 10:42:57 +0000
> 
> 
> > So Mattias's changes could only help in this case if the complete
> > backtrace will show recursive calls to print_object etc.
> 
> Let me know what you want exactly for the complete backtrace.

This:

  (gdb) thread 1
  (gdb) bt

You said earlier the backtrace produced by that is huge, so I thought
maybe just looking at the immediate cause of the segfault could give
us enough info.  But now we need to see all of it.

Thanks.

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

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


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thievol@posteo.net>
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 55832@debbugs.gnu.org
>> Date: Thu, 09 Jun 2022 10:42:57 +0000
>> 
>> 
>> > So Mattias's changes could only help in this case if the complete
>> > backtrace will show recursive calls to print_object etc.
>> 
>> Let me know what you want exactly for the complete backtrace.
>
> This:
>
>   (gdb) thread 1
>   (gdb) bt
>
> You said earlier the backtrace produced by that is huge, so I thought
> maybe just looking at the immediate cause of the segfault could give
> us enough info.  But now we need to see all of it.

Can't send here by mail it is too big 12.8M with 130303 frames, here a
link to the output file:

https://gist.github.com/thierryvolpiatto/17ee2c5631d0849e57a794e4663b71a5

Thanks.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Lars Ingebrigtsen]

Thierry Volpiatto <thievol@posteo.net> writes:

> Can't send here by mail it is too big 12.8M with 130303 frames, here a
> link to the output file:
>
> https://gist.github.com/thierryvolpiatto/17ee2c5631d0849e57a794e4663b71a5

It looks like it's throwing an error while trying to report an error:

19 0x00005555555aabe6 in Fsignal (error_symbol=<optimized out>, error_symbol@entry=0x90, data=<optimized out>) at eval.c:1689
#20 0x00005555555aac56 in xsignal (data=<optimized out>, error_symbol=0x90) at lisp.h:4528
#21 xsignal1 (error_symbol=error_symbol@entry=0x90, arg=<optimized out>) at eval.c:1849
#22 0x00005555555aac7c in verror (m=<optimized out>, ap=ap@entry=0x7fffff671760) at lisp.h:1162
#23 0x00005555555aad1b in error (m=<optimized out>) at eval.c:2052
#24 0x00005555555ad64e in exec_byte_code (fun=0x7fffff6702c0, args_template=140737478333120, nargs=2, args=0x7fffff671938) at bytecode.c:503
#25 0x00005555557ab8be in Ffuncall (nargs=3, args=0x7fffff671930) at eval.c:2953
#26 0x00005555557ac8a3 in call2 (arg2=0x55555b3fbb63, arg1=0x90, fn=<optimized out>) at lisp.h:3232
#27 signal_or_quit (error_symbol=0x90, data=0x55555b3fbb63, keyboard_quit=<optimized out>) at eval.c:1741
#28 0x00005555555aabe6 in Fsignal (error_symbol=<optimized out>, error_symbol@entry=0x90, data=<optimized out>) at eval.c:1689
#29 0x00005555555aac56 in xsignal (data=<optimized out>, error_symbol=0x90) at lisp.h:4528

That sounds vaguely familiar -- didn't we fix something in this area
lately?  Hm...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Eli Zaretskii]

> From: Thierry Volpiatto <thievol@posteo.net>
> Cc: larsi@gnus.org, 55832@debbugs.gnu.org
> Date: Thu, 09 Jun 2022 15:18:55 +0000
> 
> >   (gdb) thread 1
> >   (gdb) bt
> >
> > You said earlier the backtrace produced by that is huge, so I thought
> > maybe just looking at the immediate cause of the segfault could give
> > us enough info.  But now we need to see all of it.
> 
> Can't send here by mail it is too big 12.8M with 130303 frames, here a
> link to the output file:
> 
> https://gist.github.com/thierryvolpiatto/17ee2c5631d0849e57a794e4663b71a5

Thanks.  This is definitely a C stack overflow: there are 30 frames
that repeatedly and recursively invoke funcall and apply, like this:

  #103104 0x00005555555ad64e in exec_byte_code (fun=0x7fffff6702c0, args_template=140737478333120, nargs=3, args=0x7fffffd15a88) at bytecode.c:503
  #103105 0x00005555557ab8be in Ffuncall (nargs=4, args=0x7fffffd15a80) at eval.c:2953
  #103106 0x00005555557adf70 in Fapply (nargs=3, args=0x7fffef48ef00) at eval.c:2624
  #103107 0x0000555555806e87 in exec_byte_code (fun=0x7fffff6702c0, args_template=140737478333120, nargs=3, args=0x7fffef48ef00) at lisp.h:2182
  #103108 0x00005555557ab8be in Ffuncall (nargs=3, args=0x7fffffd15be0) at eval.c:2953
  #103109 0x00005555557adf70 in Fapply (nargs=2, args=0x7fffef48ee28) at eval.c:2624
  #103110 0x0000555555806e87 in exec_byte_code (fun=0x7fffff6702c0, args_template=140737478333120, nargs=2, args=0x7fffef48ee28) at lisp.h:2182
  #103111 0x00005555557ab8be in Ffuncall (nargs=3, args=0x7fffffd15d30) at eval.c:2953
  #103112 0x00005555557adf70 in Fapply (nargs=2, args=0x7fffef48ec58) at eval.c:2624
  #103113 0x0000555555806e87 in exec_byte_code (fun=0x7fffff6702c0, args_template=140737478333120, nargs=2, args=0x7fffef48ec58) at lisp.h:2182
  #103114 0x00005555557ab8be in Ffuncall (nargs=3, args=0x7fffffd15e80) at eval.c:2953
  #103115 0x00005555557adf70 in Fapply (nargs=2, args=0x7fffef48ea88) at eval.c:2624
  #103116 0x0000555555806e87 in exec_byte_code (fun=0x7fffff6702c0, args_template=140737478333120, nargs=2, args=0x7fffef48ea88) at lisp.h:2182
  #103117 0x00005555557ab8be in Ffuncall (nargs=3, args=0x7fffffd15fd0) at eval.c:2953
  #103118 0x00005555557adf70 in Fapply (nargs=2, args=0x7fffef48e8b8) at eval.c:2624

followed by 103,000(!) frames where Emacs tries to report an error,
and that signals another error:

  #103092 0x00005555555ad64e in exec_byte_code (fun=0x7fffff6702c0, args_template=140737478333120, nargs=0, args=0x7fffffd15790) at bytecode.c:503
  #103093 0x00005555557ab8be in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x7fffffd15788) at eval.c:2953
  #103094 0x000055555580661c in bcall0 (f=<optimized out>) at bytecode.c:335
  #103095 0x00005555557aae1f in do_one_unbind (unwinding=true, bindflag=SET_INTERNAL_UNBIND, this_binding=0x7fffffd157b0) at eval.c:3591
  #103096 unbind_to (count=..., value=value@entry=0x0) at eval.c:3719
  #103097 0x00005555555aaaf2 in unwind_to_catch (catch=catch@entry=0x555557292c10, type=type@entry=NONLOCAL_EXIT_SIGNAL, value=value@entry=0x55555b3c68a3) at lisp.h:1162
  #103098 0x00005555555aabc7 in signal_or_quit (error_symbol=<optimized out>, data=<optimized out>, keyboard_quit=<optimized out>) at eval.c:1820
  #103099 0x00005555555aabe6 in Fsignal (error_symbol=<optimized out>, error_symbol@entry=0x90, data=<optimized out>) at eval.c:1689
  #103100 0x00005555555aac56 in xsignal (data=<optimized out>, error_symbol=0x90) at lisp.h:4528
  #103101 xsignal1 (error_symbol=error_symbol@entry=0x90, arg=<optimized out>) at eval.c:1849
  #103102 0x00005555555aac7c in verror (m=<optimized out>, ap=ap@entry=0x7fffffd158e0) at lisp.h:1162
  #103103 0x00005555555aad1b in error (m=<optimized out>) at eval.c:2052

Try this:

 (gdb) source /path/to/emacs/src/.gdbinit
 (gdb) frame 8
 (gdb) p arg2
 (gdb) xtype
 (gdb) x...
 (gdb) p arg1
 (gdb) xtype
 (gdb) x...
 (gdb) frame 103105
 (gdb) p args[0]
 (gdb) xtype
 (gdb) x...
 (gdb) p args[1]
 (gdb) xtype
 (gdb) x...
 (gdb) p args[2]
 (gdb) xtype
 (gdb) x...
 (gdb) p args[3]
 (gdb) xtype
 (gdb) x...

Each time you type "xtype", GDB will display the Lisp type of the
datum.  Please invoke the corresponding x... command: xstring for
Lisp_String, xlist for Lisp_Cons, xsymbol for Lisp_Symbol, etc. --
these are the lines with "x..." above.

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

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


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thievol@posteo.net>
>> Cc: larsi@gnus.org, 55832@debbugs.gnu.org
>> Date: Thu, 09 Jun 2022 15:18:55 +0000
>> 
>> >   (gdb) thread 1
>> >   (gdb) bt
>> >
>> > You said earlier the backtrace produced by that is huge, so I thought
>> > maybe just looking at the immediate cause of the segfault could give
>> > us enough info.  But now we need to see all of it.
>> 
>> Can't send here by mail it is too big 12.8M with 130303 frames, here a
>> link to the output file:
>> 
>> https://gist.github.com/thierryvolpiatto/17ee2c5631d0849e57a794e4663b71a5
>
> Thanks.  This is definitely a C stack overflow: there are 30 frames
> that repeatedly and recursively invoke funcall and apply, like this:
>
>   #103104 0x00005555555ad64e in exec_byte_code (fun=0x7fffff6702c0, args_template=140737478333120, nargs=3, args=0x7fffffd15a88) at bytecode.c:503
>   #103105 0x00005555557ab8be in Ffuncall (nargs=4, args=0x7fffffd15a80) at eval.c:2953
>   #103106 0x00005555557adf70 in Fapply (nargs=3, args=0x7fffef48ef00) at eval.c:2624
>   #103107 0x0000555555806e87 in exec_byte_code (fun=0x7fffff6702c0, args_template=140737478333120, nargs=3, args=0x7fffef48ef00) at lisp.h:2182
>   #103108 0x00005555557ab8be in Ffuncall (nargs=3, args=0x7fffffd15be0) at eval.c:2953
>   #103109 0x00005555557adf70 in Fapply (nargs=2, args=0x7fffef48ee28) at eval.c:2624
>   #103110 0x0000555555806e87 in exec_byte_code (fun=0x7fffff6702c0, args_template=140737478333120, nargs=2, args=0x7fffef48ee28) at lisp.h:2182
>   #103111 0x00005555557ab8be in Ffuncall (nargs=3, args=0x7fffffd15d30) at eval.c:2953
>   #103112 0x00005555557adf70 in Fapply (nargs=2, args=0x7fffef48ec58) at eval.c:2624
>   #103113 0x0000555555806e87 in exec_byte_code (fun=0x7fffff6702c0, args_template=140737478333120, nargs=2, args=0x7fffef48ec58) at lisp.h:2182
>   #103114 0x00005555557ab8be in Ffuncall (nargs=3, args=0x7fffffd15e80) at eval.c:2953
>   #103115 0x00005555557adf70 in Fapply (nargs=2, args=0x7fffef48ea88) at eval.c:2624
>   #103116 0x0000555555806e87 in exec_byte_code (fun=0x7fffff6702c0, args_template=140737478333120, nargs=2, args=0x7fffef48ea88) at lisp.h:2182
>   #103117 0x00005555557ab8be in Ffuncall (nargs=3, args=0x7fffffd15fd0) at eval.c:2953
>   #103118 0x00005555557adf70 in Fapply (nargs=2, args=0x7fffef48e8b8) at eval.c:2624
>
> followed by 103,000(!) frames where Emacs tries to report an error,
> and that signals another error:
>
>   #103092 0x00005555555ad64e in exec_byte_code (fun=0x7fffff6702c0, args_template=140737478333120, nargs=0, args=0x7fffffd15790) at bytecode.c:503
>   #103093 0x00005555557ab8be in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x7fffffd15788) at eval.c:2953
>   #103094 0x000055555580661c in bcall0 (f=<optimized out>) at bytecode.c:335
>   #103095 0x00005555557aae1f in do_one_unbind (unwinding=true, bindflag=SET_INTERNAL_UNBIND, this_binding=0x7fffffd157b0) at eval.c:3591
>   #103096 unbind_to (count=..., value=value@entry=0x0) at eval.c:3719
>   #103097 0x00005555555aaaf2 in unwind_to_catch (catch=catch@entry=0x555557292c10, type=type@entry=NONLOCAL_EXIT_SIGNAL, value=value@entry=0x55555b3c68a3) at lisp.h:1162
>   #103098 0x00005555555aabc7 in signal_or_quit (error_symbol=<optimized out>, data=<optimized out>, keyboard_quit=<optimized out>) at eval.c:1820
>   #103099 0x00005555555aabe6 in Fsignal (error_symbol=<optimized out>, error_symbol@entry=0x90, data=<optimized out>) at eval.c:1689
>   #103100 0x00005555555aac56 in xsignal (data=<optimized out>, error_symbol=0x90) at lisp.h:4528
>   #103101 xsignal1 (error_symbol=error_symbol@entry=0x90, arg=<optimized out>) at eval.c:1849
>   #103102 0x00005555555aac7c in verror (m=<optimized out>, ap=ap@entry=0x7fffffd158e0) at lisp.h:1162
>   #103103 0x00005555555aad1b in error (m=<optimized out>) at eval.c:2052
>
> Try this:
>
>  (gdb) source /path/to/emacs/src/.gdbinit
>  (gdb) frame 8
>  (gdb) p arg2
>  (gdb) xtype
>  (gdb) x...
>  (gdb) p arg1
>  (gdb) xtype
>  (gdb) x...
>  (gdb) frame 103105
>  (gdb) p args[0]
>  (gdb) xtype
>  (gdb) x...
>  (gdb) p args[1]
>  (gdb) xtype
>  (gdb) x...
>  (gdb) p args[2]
>  (gdb) xtype
>  (gdb) x...
>  (gdb) p args[3]
>  (gdb) xtype
>  (gdb) x...
>
> Each time you type "xtype", GDB will display the Lisp type of the
> datum.  Please invoke the corresponding x... command: xstring for
> Lisp_String, xlist for Lisp_Cons, xsymbol for Lisp_Symbol, etc. --
> these are the lines with "x..." above.

(gdb) source /home/thierry/tmp/emacs/src/.gdbinit
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = :0.0
TERM = xterm-256color
Breakpoint 1 at 0x5555555a6b56: file emacs.c, line 420.
Breakpoint 2 at 0x5555556ba640: file xterm.c, line 22325.
(gdb) frame 8
#8  0x00005555557ac8a3 in call2 (arg2=XIL(0x55555a4b2e83), arg1=XIL(0x90), fn=<optimized out>) at lisp.h:3232
3232      return CALLN (Ffuncall, fn, arg1, arg2);
(gdb) p arg2
$1 = XIL(0x55555a4b2e83)
(gdb) xtype
Lisp_Cons
(gdb) xlist
No symbol "builtin_lisp_symbol" in current context.
(gdb) p arg1
$2 = XIL(0x90)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$3 = (struct Lisp_Symbol *) 0x555555cd6cd0 <lispsym+144>
"error"
(gdb) frame 103105
#103105 0x00005555557ab8be in Ffuncall (nargs=4, args=0x7fffffd15a80) at eval.c:2953
2953      Lisp_Object val = funcall_general (args[0], nargs - 1, args + 1);
(gdb) p args[0]
$4 = XIL(0x23a93f0)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$5 = (struct Lisp_Symbol *) 0x555558080030
"tramp-file-name-for-operation"
(gdb) p args[1]
$6 = XIL(0x22fdb90)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$7 = (struct Lisp_Symbol *) 0x555557fd47d0
"tramp-get-remote-uid"
(gdb) p args[2]
$8 = XIL(0x55555a7df8c3)
(gdb) xtype
Lisp_Cons
(gdb) xlist
No symbol "builtin_lisp_symbol" in current context.
(gdb) p args[3]
$9 = XIL(0xe940)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$10 = (struct Lisp_Symbol *) 0x555555ce5580 <lispsym+59712>
"string"

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Eli Zaretskii]

> From: Thierry Volpiatto <thievol@posteo.net>
> Cc: larsi@gnus.org, 55832@debbugs.gnu.org
> Date: Thu, 09 Jun 2022 16:51:18 +0000
> 
> (gdb) source /home/thierry/tmp/emacs/src/.gdbinit
> SIGINT is used by the debugger.
> Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
> DISPLAY = :0.0
> TERM = xterm-256color
> Breakpoint 1 at 0x5555555a6b56: file emacs.c, line 420.
> Breakpoint 2 at 0x5555556ba640: file xterm.c, line 22325.
> (gdb) frame 8
> #8  0x00005555557ac8a3 in call2 (arg2=XIL(0x55555a4b2e83), arg1=XIL(0x90), fn=<optimized out>) at lisp.h:3232
> 3232      return CALLN (Ffuncall, fn, arg1, arg2);
> (gdb) p arg2
> $1 = XIL(0x55555a4b2e83)
> (gdb) xtype
> Lisp_Cons
> (gdb) xlist
> No symbol "builtin_lisp_symbol" in current context.
> (gdb) p arg1
> $2 = XIL(0x90)
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $3 = (struct Lisp_Symbol *) 0x555555cd6cd0 <lispsym+144>
> "error"
> (gdb) frame 103105
> #103105 0x00005555557ab8be in Ffuncall (nargs=4, args=0x7fffffd15a80) at eval.c:2953
> 2953      Lisp_Object val = funcall_general (args[0], nargs - 1, args + 1);
> (gdb) p args[0]
> $4 = XIL(0x23a93f0)
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $5 = (struct Lisp_Symbol *) 0x555558080030
> "tramp-file-name-for-operation"
> (gdb) p args[1]
> $6 = XIL(0x22fdb90)
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $7 = (struct Lisp_Symbol *) 0x555557fd47d0
> "tramp-get-remote-uid"
> (gdb) p args[2]
> $8 = XIL(0x55555a7df8c3)
> (gdb) xtype
> Lisp_Cons
> (gdb) xlist
> No symbol "builtin_lisp_symbol" in current context.
> (gdb) p args[3]
> $9 = XIL(0xe940)
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $10 = (struct Lisp_Symbol *) 0x555555ce5580 <lispsym+59712>
> "string"

So tramp-file-name-for-operation errors out, and that somehow gets us
in trouble.

I see we call signal-hook-function -- what is its value in that
session, please?

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

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


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thievol@posteo.net>
>> Cc: larsi@gnus.org, 55832@debbugs.gnu.org
>> Date: Thu, 09 Jun 2022 16:51:18 +0000
>> 
>> (gdb) source /home/thierry/tmp/emacs/src/.gdbinit
>> SIGINT is used by the debugger.
>> Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
>> DISPLAY = :0.0
>> TERM = xterm-256color
>> Breakpoint 1 at 0x5555555a6b56: file emacs.c, line 420.
>> Breakpoint 2 at 0x5555556ba640: file xterm.c, line 22325.
>> (gdb) frame 8
>> #8  0x00005555557ac8a3 in call2 (arg2=XIL(0x55555a4b2e83), arg1=XIL(0x90), fn=<optimized out>) at lisp.h:3232
>> 3232      return CALLN (Ffuncall, fn, arg1, arg2);
>> (gdb) p arg2
>> $1 = XIL(0x55555a4b2e83)
>> (gdb) xtype
>> Lisp_Cons
>> (gdb) xlist
>> No symbol "builtin_lisp_symbol" in current context.
>> (gdb) p arg1
>> $2 = XIL(0x90)
>> (gdb) xtype
>> Lisp_Symbol
>> (gdb) xsymbol
>> $3 = (struct Lisp_Symbol *) 0x555555cd6cd0 <lispsym+144>
>> "error"
>> (gdb) frame 103105
>> #103105 0x00005555557ab8be in Ffuncall (nargs=4, args=0x7fffffd15a80) at eval.c:2953
>> 2953      Lisp_Object val = funcall_general (args[0], nargs - 1, args + 1);
>> (gdb) p args[0]
>> $4 = XIL(0x23a93f0)
>> (gdb) xtype
>> Lisp_Symbol
>> (gdb) xsymbol
>> $5 = (struct Lisp_Symbol *) 0x555558080030
>> "tramp-file-name-for-operation"
>> (gdb) p args[1]
>> $6 = XIL(0x22fdb90)
>> (gdb) xtype
>> Lisp_Symbol
>> (gdb) xsymbol
>> $7 = (struct Lisp_Symbol *) 0x555557fd47d0
>> "tramp-get-remote-uid"
>> (gdb) p args[2]
>> $8 = XIL(0x55555a7df8c3)
>> (gdb) xtype
>> Lisp_Cons
>> (gdb) xlist
>> No symbol "builtin_lisp_symbol" in current context.
>> (gdb) p args[3]
>> $9 = XIL(0xe940)
>> (gdb) xtype
>> Lisp_Symbol
>> (gdb) xsymbol
>> $10 = (struct Lisp_Symbol *) 0x555555ce5580 <lispsym+59712>
>> "string"
>
> So tramp-file-name-for-operation errors out, and that somehow gets us
> in trouble.
>
> I see we call signal-hook-function -- what is its value in that
> session, please?

Seems tramp let-bound it to tramp-signal-hook-function in
tramp-file-name-handler.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Eli Zaretskii]

> From: Thierry Volpiatto <thievol@posteo.net>
> Cc: larsi@gnus.org, 55832@debbugs.gnu.org
> Date: Thu, 09 Jun 2022 18:28:28 +0000
> 
> > So tramp-file-name-for-operation errors out, and that somehow gets us
> > in trouble.
> >
> > I see we call signal-hook-function -- what is its value in that
> > session, please?
> 
> Seems tramp let-bound it to tramp-signal-hook-function in
> tramp-file-name-handler.

Michael, can you help us out here?  Could the above somehow cause
infinite recursion, whereby signaling an error triggers another,
nested error?

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Michael Albinus]

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

Eli Zaretskii <eliz@gnu.org> writes:

Hi,

>> > So tramp-file-name-for-operation errors out, and that somehow gets us
>> > in trouble.
>> >
>> > I see we call signal-hook-function -- what is its value in that
>> > session, please?
>>
>> Seems tramp let-bound it to tramp-signal-hook-function in
>> tramp-file-name-handler.
>
> Michael, can you help us out here?  Could the above somehow cause
> infinite recursion, whereby signaling an error triggers another,
> nested error?

First, I've tried to reproduce it from emacs -Q. I've upgraded all
installed ELPA packages, and then I have called

--8<---------------cut here---------------start------------->8---
emacs -Q \
  -l ~/.emacs.d/elpa/helm-core-20220503.622/helm-core-autoloads.el \
  -l ~/.emacs.d/elpa/helm-20220504.827/helm-autoloads.el \
  -l ~/.emacs.d/elpa/helm-tramp-20190616.125/helm-tramp-autoloads.el \
  -l ~/.emacs.d/elpa/async-20220318.1342/async-autoloads.el \
  -l seq -f helm-find-files
--8<---------------cut here---------------end--------------->8---

Using /sudo:: as file name doesn't raise any error. However, this is
from the master branch; Emacs 28 doesn't play fine with the compiled
Helm libraries because of an error in calling string-match (using the
new optional arg INHIBIT-MODIFY). And I don't want to recompile all my
installed packages with Emacs 28. Hmm.

Looking at the error, it comes indeed from
tramp-file-name-for-operation. In the backtrace shown by Thierry it
looks like this function is called for tramp-get-remote-uid:

--8<---------------cut here---------------start------------->8---
(gdb) xsymbol
$5 = (struct Lisp_Symbol *) 0x555558080030
"tramp-file-name-for-operation"
(gdb) p args[1]
$6 = XIL(0x22fdb90)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$7 = (struct Lisp_Symbol *) 0x555557fd47d0
"tramp-get-remote-uid"
--8<---------------cut here---------------end--------------->8---

tramp-get-remote-uid *is* a valid argument, and
tramp-file-name-for-operation shouldn't raise an error. Once we have
fixed the problem of Emacs crash, it shall be investigated wy this error
has been raised.

It is not clear to me why tramp-file-name-for-operation goes into
recursion with the error handling, invoking again and again
tramp-signal-hook-function (that is the function bound to
signal-hook-function). However, a simple protection against this should
be this patch:


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

diff --git a/lisp/net/tramp.el b/lisp/net/tramp.el
index 3ee1169139..3905aeba70 100644
--- a/lisp/net/tramp.el
+++ b/lisp/net/tramp.el
@@ -2476,6 +2476,7 @@ tramp-file-name-for-operation
 It does not always return a Tramp file name, for example if the
 first argument of `expand-file-name' is absolute and not remote.
 Must be handled by the callers."
+  (let (signal-hook-function)
   (cond
    ;; FILE resp DIRECTORY.
    ((member operation
@@ -2558,7 +2559,7 @@ tramp-file-name-for-operation
    ((member operation '(tramp-get-remote-gid tramp-get-remote-uid))
     (tramp-make-tramp-file-name (nth 0 args)))
    ;; Unknown file primitive.
-   (t (error "Unknown file I/O primitive: %s" operation))))
+   (t (error "Unknown file I/O primitive: %s" operation)))))

 (defun tramp-find-foreign-file-name-handler (filename &optional _operation)
   "Return foreign file name handler if exists."

[-- Attachment #3: Type: text/plain, Size: 120 bytes --]


Similar protections have been applied already elsewhere in Tramp. Does
this solve the problem?

Best regards, Michael.

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

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


Hello Michael,

Michael Albinus <michael.albinus@gmx.de> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> Hi,
>
>>> > So tramp-file-name-for-operation errors out, and that somehow gets us
>>> > in trouble.
>>> >
>>> > I see we call signal-hook-function -- what is its value in that
>>> > session, please?
>>>
>>> Seems tramp let-bound it to tramp-signal-hook-function in
>>> tramp-file-name-handler.
>>
>> Michael, can you help us out here?  Could the above somehow cause
>> infinite recursion, whereby signaling an error triggers another,
>> nested error?
>
> First, I've tried to reproduce it from emacs -Q. I've upgraded all
> installed ELPA packages, and then I have called
>
> emacs -Q \
>   -l ~/.emacs.d/elpa/helm-core-20220503.622/helm-core-autoloads.el \
>   -l ~/.emacs.d/elpa/helm-20220504.827/helm-autoloads.el \
>   -l ~/.emacs.d/elpa/helm-tramp-20190616.125/helm-tramp-autoloads.el \

What is helm-tramp? this is not part of helm.

>   -l ~/.emacs.d/elpa/async-20220318.1342/async-autoloads.el \
>   -l seq -f helm-find-files

You have better time cloning emacs-async and run make && sudo make
install and same with helm, then emacs -q, (require 'helm) (require
'helm-config) and C-x c C-x C-f

> Using /sudo:: as file name doesn't raise any error.

Did you follow the recipe I sent?
First shot doesn't crash but second after M-x
tramp-cleanup-all-connections does.

> However, this is from the master branch;

The bug is from master branch not emacs-28, I sent the bug report from
my main emacs which is emacs-28 because 29 crashed.

> Emacs 28 doesn't play fine with the compiled Helm libraries because of
> an error in calling string-match (using the new optional arg
> INHIBIT-MODIFY). And I don't want to recompile all my installed
> packages with Emacs 28. Hmm.

The bug doesn't happen with emacs-28.

> Looking at the error, it comes indeed from
> tramp-file-name-for-operation. In the backtrace shown by Thierry it
> looks like this function is called for tramp-get-remote-uid:
>
> (gdb) xsymbol
> $5 = (struct Lisp_Symbol *) 0x555558080030
> "tramp-file-name-for-operation"
> (gdb) p args[1]
> $6 = XIL(0x22fdb90)
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $7 = (struct Lisp_Symbol *) 0x555557fd47d0
> "tramp-get-remote-uid"
>
> tramp-get-remote-uid *is* a valid argument, and
> tramp-file-name-for-operation shouldn't raise an error. Once we have
> fixed the problem of Emacs crash, it shall be investigated wy this error
> has been raised.

tramp-get-remote-uid is calling tramp-file-name-handler with
tramp-get-remote-uid as arg so I guess the infinite recursion starts
here isn't it?
 
> It is not clear to me why tramp-file-name-for-operation goes into
> recursion with the error handling, invoking again and again
> tramp-signal-hook-function (that is the function bound to
> signal-hook-function).

What is calling tramp-get-remote-uid in tramp-file-name-for-operation?

> However, a simple protection against this should be this patch:
>
> diff --git a/lisp/net/tramp.el b/lisp/net/tramp.el
> index 3ee1169139..3905aeba70 100644
> --- a/lisp/net/tramp.el
> +++ b/lisp/net/tramp.el
> @@ -2476,6 +2476,7 @@ tramp-file-name-for-operation
>  It does not always return a Tramp file name, for example if the
>  first argument of `expand-file-name' is absolute and not remote.
>  Must be handled by the callers."
> +  (let (signal-hook-function)
>    (cond
>     ;; FILE resp DIRECTORY.
>     ((member operation
> @@ -2558,7 +2559,7 @@ tramp-file-name-for-operation
>     ((member operation '(tramp-get-remote-gid tramp-get-remote-uid))
>      (tramp-make-tramp-file-name (nth 0 args)))
>     ;; Unknown file primitive.
> -   (t (error "Unknown file I/O primitive: %s" operation))))
> +   (t (error "Unknown file I/O primitive: %s" operation)))))
>
>  (defun tramp-find-foreign-file-name-handler (filename &optional _operation)
>    "Return foreign file name handler if exists."
>
>
> Similar protections have been applied already elsewhere in Tramp. Does
> this solve the problem?

No still crashing.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Michael Albinus]

Thierry Volpiatto <thievol@posteo.net> writes:

> Hello Michael,

Hi Thierry,

>> First, I've tried to reproduce it from emacs -Q. I've upgraded all
>> installed ELPA packages, and then I have called
>>
>> emacs -Q \
>>   -l ~/.emacs.d/elpa/helm-core-20220503.622/helm-core-autoloads.el \
>>   -l ~/.emacs.d/elpa/helm-20220504.827/helm-autoloads.el \
>>   -l ~/.emacs.d/elpa/helm-tramp-20190616.125/helm-tramp-autoloads.el \
>
> What is helm-tramp? this is not part of helm.

I've installed this as ELPA package a while ago, don't remember the
details. So I've taken this out, calling now Emacs master branch like

emacs -Q \
  -l ~/.emacs.d/elpa/helm-core-20220503.622/helm-core-autoloads.el \
  -l ~/.emacs.d/elpa/helm-20220504.827/helm-autoloads.el \
  -l ~/.emacs.d/elpa/async-20220318.1342/async-autoloads.el -l seq

> You have better time cloning emacs-async and run make && sudo make
> install and same with helm, then emacs -q, (require 'helm) (require
> 'helm-config) and C-x c C-x C-f

Hmm, this would poison my laptop with an undesired config. Shouldn't the
call above be sufficient?

>> Using /sudo:: as file name doesn't raise any error.
>
> Did you follow the recipe I sent?
> First shot doesn't crash but second after M-x
> tramp-cleanup-all-connections does.

Ahh, this was another message I didn't notice.

>> However, this is from the master branch;
>
> The bug is from master branch not emacs-28, I sent the bug report from
> my main emacs which is emacs-28 because 29 crashed.

OK, rerunning your recipe with the invocation as above:

> 1) Ensure you have no entries for sudo in .authinfo.gpg file.

Not needed, because I call "emacs -Q".

> 2) M-x helm-find-files RET // sudo::

Done.

> 3) You are prompted for password

Yep.

> 4) At this first shot it should work as expected.

Not clear to me whether I shall enter the password. I did. Now Helm
offers me something, which I always confirm with RET, until I see the
dired buffer of "/sudo:root@gandalf:/root". "gandalf" is the name of my laptop.

> 5) C-g to quit, and M-x tramp-cleanup-all-connections.

Done.

> 6) Restart helm-find-files and enter /sudo:: emacs should freeze and crash.

I've switched to the *scratch* buffer, and did this. No problem.

-----

Now a second attempt. Steps 1-3 as above.

> 4) At this first shot it should work as expected.

I didn't enter the password.

> 5) C-g to quit, and M-x tramp-cleanup-all-connections.

Done. I have applied C-g twice in order to go out of the minibuffer.

> 6) Restart helm-find-files and enter /sudo:: emacs should freeze and crash.

No, Emacs asks me for the /sudo:: password, and continues as expected.

>> tramp-get-remote-uid *is* a valid argument, and
>> tramp-file-name-for-operation shouldn't raise an error. Once we have
>> fixed the problem of Emacs crash, it shall be investigated wy this error
>> has been raised.
>
> tramp-get-remote-uid is calling tramp-file-name-handler with
> tramp-get-remote-uid as arg so I guess the infinite recursion starts
> here isn't it?

No. tramp-get-remote-uid invokes tramp-file-name-handler in order to get
a method specific implementation (finally, tramp-sh-handle-get-remote-uid
shall be called).

>> It is not clear to me why tramp-file-name-for-operation goes into
>> recursion with the error handling, invoking again and again
>> tramp-signal-hook-function (that is the function bound to
>> signal-hook-function).
>
> What is calling tramp-get-remote-uid in tramp-file-name-for-operation?

tramp-get-remote-uid should *not* be called inside
tramp-file-name-for-operation.  The symbol is passed as argument, and
used for investigation of the other args.

>> Similar protections have been applied already elsewhere in Tramp. Does
>> this solve the problem?
>
> No still crashing.

Sad. Since I cannot reproduce the problem locally, what happens if you
invoke "emacs -Q" similar to how I've done?

Best regards, Michael.

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

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


Michael Albinus <michael.albinus@gmx.de> writes:

> Thierry Volpiatto <thievol@posteo.net> writes:
>
>> Hello Michael,
>
> Hi Thierry,
>
>>> First, I've tried to reproduce it from emacs -Q. I've upgraded all
>>> installed ELPA packages, and then I have called
>>>
>>> emacs -Q \
>>>   -l ~/.emacs.d/elpa/helm-core-20220503.622/helm-core-autoloads.el \
>>>   -l ~/.emacs.d/elpa/helm-20220504.827/helm-autoloads.el \
>>>   -l ~/.emacs.d/elpa/helm-tramp-20190616.125/helm-tramp-autoloads.el \
>>
>> What is helm-tramp? this is not part of helm.
>
> I've installed this as ELPA package a while ago, don't remember the
> details. So I've taken this out, calling now Emacs master branch like
>
> emacs -Q \
>   -l ~/.emacs.d/elpa/helm-core-20220503.622/helm-core-autoloads.el \
>   -l ~/.emacs.d/elpa/helm-20220504.827/helm-autoloads.el \
>   -l ~/.emacs.d/elpa/async-20220318.1342/async-autoloads.el -l seq
>
>> You have better time cloning emacs-async and run make && sudo make
>> install and same with helm, then emacs -q, (require 'helm) (require
>> 'helm-config) and C-x c C-x C-f
>
> Hmm, this would poison my laptop with an undesired config. Shouldn't the
> call above be sufficient?
>
>>> Using /sudo:: as file name doesn't raise any error.
>>
>> Did you follow the recipe I sent?
>> First shot doesn't crash but second after M-x
>> tramp-cleanup-all-connections does.
>
> Ahh, this was another message I didn't notice.
>
>>> However, this is from the master branch;
>>
>> The bug is from master branch not emacs-28, I sent the bug report from
>> my main emacs which is emacs-28 because 29 crashed.
>
> OK, rerunning your recipe with the invocation as above:
>
>> 1) Ensure you have no entries for sudo in .authinfo.gpg file.
>
> Not needed, because I call "emacs -Q".
>
>> 2) M-x helm-find-files RET // sudo::
>
> Done.
>
>> 3) You are prompted for password
>
> Yep.
>
>> 4) At this first shot it should work as expected.
>
> Not clear to me whether I shall enter the password.

If you are prompted for password of course you have to enter your password.

> I did. Now Helm offers me something, which I always confirm with RET,

Helm offers you completion on your system files and offer you to
navigate with arrow keys or C-j C-l, if you press RET on a directory it
opens this directory in a dired buffer, on a file in a buffer to edit file.

> No. tramp-get-remote-uid invokes tramp-file-name-handler in order to get
> a method specific implementation (finally, tramp-sh-handle-get-remote-uid
> shall be called).

Ah ok, I noticed I have always in ~/.emacs.d/tramp an UNKNOW entry for
uid and gid, is it normal?

>>> It is not clear to me why tramp-file-name-for-operation goes into
>>> recursion with the error handling, invoking again and again
>>> tramp-signal-hook-function (that is the function bound to
>>> signal-hook-function).
>>
>> What is calling tramp-get-remote-uid in tramp-file-name-for-operation?
>
> tramp-get-remote-uid should *not* be called inside
> tramp-file-name-for-operation.  The symbol is passed as argument, and
> used for investigation of the other args.
>
>>> Similar protections have been applied already elsewhere in Tramp. Does
>>> this solve the problem?
>>
>> No still crashing.
>
> Sad. Since I cannot reproduce the problem locally, what happens if you
> invoke "emacs -Q" similar to how I've done?

I can't reproduce the crash using helm -P path/to/emacs though there is
not much difference with my helm-find-files config, the difference comes
I guess from the usage of normal emacs (or possibly only -q) and emacs
-Q which affect tramp in some ways.

What I would like to understand is why the crash appears AFTER
tramp-cleanup-all-connections and not before on first shot.


-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Michael Albinus]

Thierry Volpiatto <thievol@posteo.net> writes:

Hi Thierry,

> Ah ok, I noticed I have always in ~/.emacs.d/tramp an UNKNOW entry for
> uid and gid, is it normal?

When the remote uid or gid cannot be determined, Tramp sets the default
value "UNKNOWN" (for the uid-string resp. remote-gid property), and -1
(for the uid-integer resp. gid-integer property). See
tramp-unknown-id-string and tramp-unknown-id-integer.

However, I would be surprised if these values are used for a "sudo"
connection. Checking my own ~/.emacs.d/tramp I find such entries,
indeed, for a "sudo" connection. Very strange. But although incorrect,
they haven't disturbed my use of Tramp.

After exiting Emacs, deleting ~/.emacs.d/tramp, and starting Emacs again
with a "sudo" connection, there arer proper values "root" and 0 in the
cached properties. Hmm, don't know where these values came from in
history, but I don't believe they should disturb Tramp. But who
knows. Perhaps you move the ~/.emacs.d/tramp file away (in order to use
it later if necessary), start a new Emacs instance, and see, whether it
still crashes with your scenario.

>> Sad. Since I cannot reproduce the problem locally, what happens if you
>> invoke "emacs -Q" similar to how I've done?
>
> I can't reproduce the crash using helm -P path/to/emacs though there is
> not much difference with my helm-find-files config, the difference comes
> I guess from the usage of normal emacs (or possibly only -q) and emacs
> -Q which affect tramp in some ways.
>
> What I would like to understand is why the crash appears AFTER
> tramp-cleanup-all-connections and not before on first shot.

Also a mystery to me.

If the removing of the ~/.emacs.d/tramp file does not help, you might
try the following settings:

--8<---------------cut here---------------start------------->8---
(setq tramp-verbose 10 tramp-debug-to-file t)
--8<---------------cut here---------------end--------------->8---

This increases the Tramp debug messages volume, and writes those
messages to disk at /tmp as they appear, under a file name like the
Tramp debug buffer name. So we have something to analyze even after
crash.

Well, reading the Helm sources, you'll better with setting
helm-tramp-verbose.

Best regards, Michael.

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

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


Michael Albinus <michael.albinus@gmx.de> writes:

> Thierry Volpiatto <thievol@posteo.net> writes:
>
> Hi Thierry,
>
>> Ah ok, I noticed I have always in ~/.emacs.d/tramp an UNKNOW entry for
>> uid and gid, is it normal?
>
> When the remote uid or gid cannot be determined, Tramp sets the default
> value "UNKNOWN" (for the uid-string resp. remote-gid property), and -1
> (for the uid-integer resp. gid-integer property). See
> tramp-unknown-id-string and tramp-unknown-id-integer.
>
> However, I would be surprised if these values are used for a "sudo"
> connection. Checking my own ~/.emacs.d/tramp I find such entries,
> indeed, for a "sudo" connection. Very strange. But although incorrect,
> they haven't disturbed my use of Tramp.
>
> After exiting Emacs, deleting ~/.emacs.d/tramp, and starting Emacs again
> with a "sudo" connection, there arer proper values "root" and 0 in the
> cached properties. Hmm, don't know where these values came from in
> history, but I don't believe they should disturb Tramp. But who
> knows. Perhaps you move the ~/.emacs.d/tramp file away (in order to use
> it later if necessary), start a new Emacs instance, and see, whether it
> still crashes with your scenario.

Will try this now.

>>> Sad. Since I cannot reproduce the problem locally, what happens if you
>>> invoke "emacs -Q" similar to how I've done?
>>
>> I can't reproduce the crash using helm -P path/to/emacs though there is
>> not much difference with my helm-find-files config, the difference comes
>> I guess from the usage of normal emacs (or possibly only -q) and emacs
>> -Q which affect tramp in some ways.
>>
>> What I would like to understand is why the crash appears AFTER
>> tramp-cleanup-all-connections and not before on first shot.
>
> Also a mystery to me.
>
> If the removing of the ~/.emacs.d/tramp file does not help, you might
> try the following settings:
>
> (setq tramp-verbose 10 tramp-debug-to-file t)

Ah nice, with those setting instead of crashing emacs hang and I can
recuperate with C-g, here the tramp log:

https://gist.github.com/thierryvolpiatto/96b5d3bacc92deac1fad275eede69354

Thanks.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Michael Albinus]

Thierry Volpiatto <thievol@posteo.net> writes:

Hi Thierry,

>> (setq tramp-verbose 10 tramp-debug-to-file t)
>
> Ah nice, with those setting instead of crashing emacs hang and I can
> recuperate with C-g, here the tramp log:
>
> https://gist.github.com/thierryvolpiatto/96b5d3bacc92deac1fad275eede69354

Thanks. The trace looks surprising, again and again

--8<---------------cut here---------------start------------->8---
21:38:47.713417 tramp-get-remote-id (5) # Finding POSIX `id' command
--8<---------------cut here---------------end--------------->8---

I'll try to analyze tomorrow what could have triggered this behavior. If
not successful, I'll ask you for instrumentation of Tramp.

> Thanks.

Best regards, Michael.

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

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


Michael Albinus <michael.albinus@gmx.de> writes:

> Thierry Volpiatto <thievol@posteo.net> writes:
>
> Hi Thierry,
>
>>> (setq tramp-verbose 10 tramp-debug-to-file t)
>>
>> Ah nice, with those setting instead of crashing emacs hang and I can
>> recuperate with C-g, here the tramp log:
>>
>> https://gist.github.com/thierryvolpiatto/96b5d3bacc92deac1fad275eede69354
>
> Thanks. The trace looks surprising, again and again
>
> 21:38:47.713417 tramp-get-remote-id (5) # Finding POSIX `id' command
>
> I'll try to analyze tomorrow what could have triggered this behavior. If
> not successful, I'll ask you for instrumentation of Tramp.

Thanks.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

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


Michael Albinus <michael.albinus@gmx.de> writes:

> Thierry Volpiatto <thievol@posteo.net> writes:
>
> Hi Thierry,
>
>>> (setq tramp-verbose 10 tramp-debug-to-file t)
>>
>> Ah nice, with those setting instead of crashing emacs hang and I can
>> recuperate with C-g, here the tramp log:
>>
>> https://gist.github.com/thierryvolpiatto/96b5d3bacc92deac1fad275eede69354
>
> Thanks. The trace looks surprising, again and again
>
> 21:38:47.713417 tramp-get-remote-id (5) # Finding POSIX `id' command
>
> I'll try to analyze tomorrow what could have triggered this behavior. If
> not successful, I'll ask you for instrumentation of Tramp.

I have a function wrote long time ago to delete tramp connections which
is not working (or most of the time not working) because it uses
tramp-list-connections which is itself broken (unexpectedly it worked
only once today don't know why).

The test (tramp-connection-property-p key "process-buffer") is wrong IMO
according to the data fetched from tramp-cache-data, here a function based
on tramp-list-connections to illustrate the data fetched here from a
sudo connection:

    (defun tv/list-tramp-connections ()
      (cl-loop with tramp-verbose = 0
               for key being the hash-keys in tramp-cache-data
               using (hash-value val)
               when (and (tramp-file-name-p key)
    		     (null (tramp-file-name-localname key))
                         ;; (tramp-connection-property-p key "process-buffer"))
                         )
               collect (list key (cl-loop for k being the hash-keys in val
                                          using (hash-value v)
                                          collect (list k v))))

The function for a sudo connection returns:

(((tramp-file-name "sudo"
                   #("root" 0 4
                     (tramp-default t))
                   nil
                   #("IPad-S340" 0 9
                     (tramp-default t))
                   nil nil nil)
  (("process-buffer" nil)
   ("null-device" "/dev/null")
   ("uid-string" "UNKNOWN")
   ("gid-string" "UNKNOWN")
   ("uid-integer" -1)
   ("gid-integer" -1)
   ("first-password-request" nil)
   ("uname" "Linux 5.15.0-33-generic")
   ("locale" "LC_ALL=en_US.utf8")
   ("test" "test")
   ("remote-path"
    ("/bin" "/usr/bin" "/sbin" "/usr/sbin" "/usr/local/bin" "/usr/local/sbin"))
   ("pipe-buf" 4096)
   ("remote-shell" "/bin/sh")
   ("~root" "/root")
   ("file-exists" "test -e")
   ("stat" "env QUOTING_STYLE=locale \\stat")
   ("case-insensitive" nil)
   ("readlink" "\\readlink"))))

As you can see "process-buffer" is listed in the cdr but not the car of
result so tramp-list-connections always returns nil because
(tramp-connection-property-p key "process-buffer") always returns nil.

Seems the cdr is the same as what found in ~/.emacs.d/tramp.

Maybe it can help you to understand what's going wrong.

Thanks.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Michael Albinus]

Thierry Volpiatto <thievol@posteo.net> writes:

Hi Thierry,

> I have a function wrote long time ago to delete tramp connections which
> is not working (or most of the time not working) because it uses
> tramp-list-connections which is itself broken (unexpectedly it worked
> only once today don't know why).
>
> The test (tramp-connection-property-p key "process-buffer") is wrong IMO
> according to the data fetched from tramp-cache-data,

I don't understand this. tramp-connection-property-p just tests whether
a connection property is defined. It does not check the value of this property.

> here a function based
> on tramp-list-connections to illustrate the data fetched here from a
> sudo connection:
>
>     (defun tv/list-tramp-connections ()
>       (cl-loop with tramp-verbose = 0
>                for key being the hash-keys in tramp-cache-data
>                using (hash-value val)
>                when (and (tramp-file-name-p key)
>     		     (null (tramp-file-name-localname key))
>                          ;; (tramp-connection-property-p key "process-buffer"))
>                          )
>                collect (list key (cl-loop for k being the hash-keys in val
>                                           using (hash-value v)
>                                           collect (list k v))))

Sorry, but I'm not fluent with the cl-loop syntax.

> The function for a sudo connection returns:
>
> (((tramp-file-name "sudo"
>                    #("root" 0 4
>                      (tramp-default t))
>                    nil
>                    #("IPad-S340" 0 9
>                      (tramp-default t))
>                    nil nil nil)
>   (("process-buffer" nil)
>    ("null-device" "/dev/null")
>    ("uid-string" "UNKNOWN")
>    ("gid-string" "UNKNOWN")
>    ("uid-integer" -1)
>    ("gid-integer" -1)
>    ("first-password-request" nil)
>    ("uname" "Linux 5.15.0-33-generic")
>    ("locale" "LC_ALL=en_US.utf8")
>    ("test" "test")
>    ("remote-path"
>     ("/bin" "/usr/bin" "/sbin" "/usr/sbin" "/usr/local/bin" "/usr/local/sbin"))
>    ("pipe-buf" 4096)
>    ("remote-shell" "/bin/sh")
>    ("~root" "/root")
>    ("file-exists" "test -e")
>    ("stat" "env QUOTING_STYLE=locale \\stat")
>    ("case-insensitive" nil)
>    ("readlink" "\\readlink"))))
>
> As you can see "process-buffer" is listed in the cdr but not the car of
> result so tramp-list-connections always returns nil because
> (tramp-connection-property-p key "process-buffer") always returns nil.
>
> Seems the cdr is the same as what found in ~/.emacs.d/tramp.

Sorry, I cannot follow what you try to explain. Could you please show me
an example, both the value of tramp-cache-data, and the result
tramp-list-connections is returning?

> Maybe it can help you to understand what's going wrong.

At least it is unrelated to the problem of this bug report.

> Thanks.

Best regards, Michael.

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

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


Michael Albinus <michael.albinus@gmx.de> writes:

> Thierry Volpiatto <thievol@posteo.net> writes:
>
> Hi Thierry,
>
>> I have a function wrote long time ago to delete tramp connections which
>> is not working (or most of the time not working) because it uses
>> tramp-list-connections which is itself broken (unexpectedly it worked
>> only once today don't know why).
>>
>> The test (tramp-connection-property-p key "process-buffer") is wrong IMO
>> according to the data fetched from tramp-cache-data,
>
> I don't understand this. tramp-connection-property-p just tests whether
> a connection property is defined.

Where? in key or value?

> It does not check the value of this property.

> Sorry, I cannot follow what you try to explain. Could you please show me
> an example, both the value of tramp-cache-data, and the result
> tramp-list-connections is returning?

tramp-list-connections is often returning nil whatever the value of
tramp-cache-data is but I have no recipe to reproduce this reliabily, if
I can make a recipe when I have time I will report it, for now perhaps
you can forget it.

Thanks.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

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


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thievol@posteo.net>
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 55832@debbugs.gnu.org
>> Date: Thu, 09 Jun 2022 10:42:57 +0000
>> 
>> 
>> > So Mattias's changes could only help in this case if the complete
>> > backtrace will show recursive calls to print_object etc.
>> 
>> Let me know what you want exactly for the complete backtrace.
>
> This:
>
>   (gdb) thread 1
>   (gdb) bt
>
> You said earlier the backtrace produced by that is huge, so I thought
> maybe just looking at the immediate cause of the segfault could give
> us enough info.  But now we need to see all of it.

I am now able to reproduce at each time like this with helm:

1) Ensure you have no entries for sudo in .authinfo.gpg file.
2) M-x helm-find-files RET // sudo::
3) You are prompted for password
4) At this first shot it should work as expected.
5) C-g to quit, and M-x tramp-cleanup-all-connections.
6) Restart helm-find-files and enter /sudo:: emacs should freeze and
crash.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Michael Albinus]

Thierry Volpiatto <thievol@posteo.net> writes:

Hi Thierry,

sorry for the delay, I've been occupied by other duties last days.

>>>> (setq tramp-verbose 10 tramp-debug-to-file t)
>>>
>>> Ah nice, with those setting instead of crashing emacs hang and I can
>>> recuperate with C-g, here the tramp log:
>>>
>>> https://gist.github.com/thierryvolpiatto/96b5d3bacc92deac1fad275eede69354
>>
>> Thanks. The trace looks surprising, again and again
>>
>> 21:38:47.713417 tramp-get-remote-id (5) # Finding POSIX `id' command
>>
>> I'll try to analyze tomorrow what could have triggered this behavior. If
>> not successful, I'll ask you for instrumentation of Tramp.
>
> Thanks.

Finally,  I could reproduce the problem with the following code snippet:

--8<---------------cut here---------------start------------->8---
(progn
  (tramp-cleanup-all-connections)
  (let ((non-essential t))
    (tramp-get-remote-uid (tramp-dissect-file-name "/sudo::") 'string)))
--8<---------------cut here---------------end--------------->8---

I've pushed a fix to master, could you please check?

Best regards, Michael.

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

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


Michael Albinus <michael.albinus@gmx.de> writes:

> Thierry Volpiatto <thievol@posteo.net> writes:
>
> Hi Thierry,
>
> sorry for the delay, I've been occupied by other duties last days.
>
>>>>> (setq tramp-verbose 10 tramp-debug-to-file t)
>>>>
>>>> Ah nice, with those setting instead of crashing emacs hang and I can
>>>> recuperate with C-g, here the tramp log:
>>>>
>>>> https://gist.github.com/thierryvolpiatto/96b5d3bacc92deac1fad275eede69354
>>>
>>> Thanks. The trace looks surprising, again and again
>>>
>>> 21:38:47.713417 tramp-get-remote-id (5) # Finding POSIX `id' command
>>>
>>> I'll try to analyze tomorrow what could have triggered this behavior. If
>>> not successful, I'll ask you for instrumentation of Tramp.
>>
>> Thanks.
>
> Finally,  I could reproduce the problem with the following code snippet:
>
> (progn
>   (tramp-cleanup-all-connections)
>   (let ((non-essential t))
>     (tramp-get-remote-uid (tramp-dissect-file-name "/sudo::") 'string)))
>
> I've pushed a fix to master, could you please check?

Did two or three tries without crashing :-) seems fixed.

Thanks Michael and Eli for gdb lesson ;-).

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Michael Albinus]

Version: 29.1

Thierry Volpiatto <thievol@posteo.net> writes:

Hi Thierry,

>> I've pushed a fix to master, could you please check?
>
> Did two or three tries without crashing :-) seems fixed.

Thanks for confirmation, I'm closing the bug.

> Thanks Michael and Eli for gdb lesson ;-).

Best regards, Michael.

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Michael Albinus]

Thierry Volpiatto <thievol@posteo.net> writes:

Hi Thierry,

>>> I have a function wrote long time ago to delete tramp connections which
>>> is not working (or most of the time not working) because it uses
>>> tramp-list-connections which is itself broken (unexpectedly it worked
>>> only once today don't know why).
>>>
>>> The test (tramp-connection-property-p key "process-buffer") is wrong IMO
>>> according to the data fetched from tramp-cache-data,
>>
>> I don't understand this. tramp-connection-property-p just tests whether
>> a connection property is defined.
>
> Where? in key or value?

Key.

> tramp-list-connections is often returning nil whatever the value of
> tramp-cache-data is but I have no recipe to reproduce this reliabily, if
> I can make a recipe when I have time I will report it, for now perhaps
> you can forget it.

Hmm. Start "emacs -Q -l tramp". Then in *scratch*

;; There's an empty cache.
tramp-cache-data
=> #s(hash-table size 65 test equal rehash-size 1.5 rehash-threshold 0.8125 data ())

;; Open a connection.
(file-attributes "/sudo::")
=> (t 9 0 0 (25256 27751 0 0) (25256 48385 0 0) (25256 48385 0 0) 4096 "dr-xr-x---" nil 2621441 (-1 . 1))

;; The cache contains an entry for this connection, and this entry
;; contains the property "process-buffer" with value nil.
(pp tramp-cache-data)
=> #s(hash-table size 65 test equal rehash-size 1.5 rehash-threshold 0.8125 data
	      ((tramp-file-name "sudo"
				#("root" 0 4
				  (tramp-default t))
				nil
				#("gandalf" 0 7
				  (tramp-default t))
				nil nil nil)
	       #s(hash-table size 65 test equal rehash-size 1.5 rehash-threshold 0.8125 data
			     ("null-device" "/dev/null" "process-buffer" nil "uname" "Linux 5.17.12-300.fc36.x86_64" "locale" "LC_ALL=en_US.utf8" "test" "test" "remote-path"
			      ("/usr/bin" "/bin" "/sbin" "/usr/sbin" "/usr/local/bin" "/usr/local/sbin")
			      "pipe-buf" 4096 "remote-shell" "/bin/sh"
			      #("~root" 1 5
				(tramp-default t))
			      "/root" "stat" "env QUOTING_STYLE=locale \\stat" "id" "/usr/bin/id" "gid-integer" 0))
   ...

;; Here we see that "process-buffer" is declared.
(tramp-connection-property-p (tramp-dissect-file-name "/sudo::") "process-buffer")
=> t

(tramp-list-connections)
=> ((tramp-file-name sudo root nil gandalf nil nil nil))

;; Now wait ca 5 min, until you see the message
;; "Tramp: Timeout session /sudo:root@gandalf:".
(tramp-connection-property-p (tramp-dissect-file-name "/sudo::") "process-buffer")
=> nil

(tramp-list-connections)
=> nil

> Thanks.

Best regards, Michael.

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Michael Albinus]

Thierry Volpiatto <thievol@posteo.net> writes:

Hi Thierry,

> tramp-list-connections is often returning nil whatever the value of
> tramp-cache-data is but I have no recipe to reproduce this reliabily, if
> I can make a recipe when I have time I will report it, for now perhaps
> you can forget it.

I made a code review of using property "process-buffer" in Tramp, and
there is indeed a case it behaves incorrectly: after spawning an
asynchronous process. Recipe:

--8<---------------cut here---------------start------------->8---
# emacs -Q /sudo::

M-: (tramp-list-connections)
=> ((tramp-file-name "sudo" #("root" 0 4 (tramp-default t)) nil #("gandalf" 0 7 (tramp-default t)) nil nil nil))

M-x async-shell-command RET ls

M-: (tramp-list-connections)
nil
--8<---------------cut here---------------end--------------->8---

I'm working on a fix.

> Thanks.

Best regards, Michael.

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

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


Hi Michael,

Michael Albinus <michael.albinus@gmx.de> writes:

> Thierry Volpiatto <thievol@posteo.net> writes:
>
> Hi Thierry,
>
>> tramp-list-connections is often returning nil whatever the value of
>> tramp-cache-data is but I have no recipe to reproduce this reliabily, if
>> I can make a recipe when I have time I will report it, for now perhaps
>> you can forget it.
>
> I made a code review of using property "process-buffer" in Tramp, and
> there is indeed a case it behaves incorrectly: after spawning an
> asynchronous process. Recipe:
>
> # emacs -Q /sudo::
>
> M-: (tramp-list-connections)
> => ((tramp-file-name "sudo" #("root" 0 4 (tramp-default t)) nil #("gandalf" 0 7 (tramp-default t)) nil nil nil))
>
> M-x async-shell-command RET ls

Probably there is something else than this but couldn't figure out what, I
will let you know if I find other use cases.

> M-: (tramp-list-connections)
> nil
>
> I'm working on a fix.

Great thanks.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Michael Albinus]

Thierry Volpiatto <thievol@posteo.net> writes:

> Hi Michael,

Hi Thierry,

>> I made a code review of using property "process-buffer" in Tramp, and
>> there is indeed a case it behaves incorrectly: after spawning an
>> asynchronous process. Recipe:
>>
>> # emacs -Q /sudo::
>>
>> M-: (tramp-list-connections)
>> => ((tramp-file-name "sudo" #("root" 0 4 (tramp-default t)) nil #("gandalf" 0 7 (tramp-default t)) nil nil nil))
>>
>> M-x async-shell-command RET ls
>
> Probably there is something else than this but couldn't figure out what, I
> will let you know if I find other use cases.

According to the code review, out-of-band methods (like "scp") are
suspicious, too. And there might be some corner cases with the "smb" method.

I haven't tried to compose further recipes for problematic cases. I have
simply changed the handling of the "process-buffer" and "process-name"
properties in all Tramp files. This shall be good enough.

>> M-: (tramp-list-connections)
>> nil
>>
>> I'm working on a fix.
>
> Great thanks.

I've pushed the fix to master.

Best regards, Michael.

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

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


Hi Michael,

Michael Albinus <michael.albinus@gmx.de> writes:

> Thierry Volpiatto <thievol@posteo.net> writes:
>
>> Hi Michael,
>
> Hi Thierry,
>
>>> I made a code review of using property "process-buffer" in Tramp, and
>>> there is indeed a case it behaves incorrectly: after spawning an
>>> asynchronous process. Recipe:
>>>
>>> # emacs -Q /sudo::
>>>
>>> M-: (tramp-list-connections)
>>> => ((tramp-file-name "sudo" #("root" 0 4 (tramp-default t)) nil #("gandalf" 0 7 (tramp-default t)) nil nil nil))
>>>
>>> M-x async-shell-command RET ls
>>
>> Probably there is something else than this but couldn't figure out what, I
>> will let you know if I find other use cases.
>
> According to the code review, out-of-band methods (like "scp") are
> suspicious, too. And there might be some corner cases with the "smb" method.

Ok, I sometimes use scp but more rarely now that I have a rsync command
in helm, also last time I tried, scp method was not supporting more than
three file at the time (marked files), see
https://github.com/emacs-helm/helm/issues/1945.  
For smb I never used it. 

> I haven't tried to compose further recipes for problematic cases. I have
> simply changed the handling of the "process-buffer" and "process-name"
> properties in all Tramp files. This shall be good enough.

Ok thanks.

>>> M-: (tramp-list-connections)
>>> nil
>>>
>>> I'm working on a fix.
>>
>> Great thanks.
>
> I've pushed the fix to master.

Thanks, will try as soon as possible.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Michael Albinus]

Thierry Volpiatto <thievol@posteo.net> writes:

Hi Thierry,

> Ok, I sometimes use scp but more rarely now that I have a rsync command
> in helm, also last time I tried, scp method was not supporting more than
> three file at the time (marked files), see
> https://github.com/emacs-helm/helm/issues/1945.

Hmm, I don't remember a bug report. Let's see whether I can reproduce this.

Best regards, Michael.

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

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


Michael Albinus <michael.albinus@gmx.de> writes:

> Thierry Volpiatto <thievol@posteo.net> writes:
>
> Hi Thierry,
>
>> Ok, I sometimes use scp but more rarely now that I have a rsync command
>> in helm, also last time I tried, scp method was not supporting more than
>> three file at the time (marked files), see
>> https://github.com/emacs-helm/helm/issues/1945.
>
> Hmm, I don't remember a bug report.

IIRC I found a old bug report about this you fixed, but it seems it have
been reintroduced last time I checked, maybe it is fixed again now (I have no
ssh server under hand to verify right now).

> Let's see whether I can reproduce this.

Thanks.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Michael Albinus]

Thierry Volpiatto <thievol@posteo.net> writes:

Hi Thierry,

> IIRC I found a old bug report about this you fixed, but it seems it have
> been reintroduced last time I checked, maybe it is fixed again now (I have no
> ssh server under hand to verify right now).

Do you remember the bug number?

> Thanks.

Best regards, Michael.

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Michael Albinus]

Thierry Volpiatto <thievol@posteo.net> writes:

Hi Thierry,

>>> Ok, I sometimes use scp but more rarely now that I have a rsync command
>>> in helm, also last time I tried, scp method was not supporting more than
>>> three file at the time (marked files), see
>>> https://github.com/emacs-helm/helm/issues/1945.
>>
>> Hmm, I don't remember a bug report.
>
> IIRC I found a old bug report about this you fixed, but it seems it have
> been reintroduced last time I checked, maybe it is fixed again now (I have no
> ssh server under hand to verify right now).
>
>> Let's see whether I can reproduce this.

Well, I've opened a remote scp connection, visiting a dired
buffer. There, I have marked five different files (large enough). These
files I've copied via dired-do-copy to another remote machine, also
connected via scp. Everything works fine.

If you see such a problem again, please write a new bug report.

> Thanks.

Best regards, Michael.

bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto]

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


Michael Albinus <michael.albinus@gmx.de> writes:

> Thierry Volpiatto <thievol@posteo.net> writes:
>
> Hi Thierry,
>
>>>> Ok, I sometimes use scp but more rarely now that I have a rsync command
>>>> in helm, also last time I tried, scp method was not supporting more than
>>>> three file at the time (marked files), see
>>>> https://github.com/emacs-helm/helm/issues/1945.
>>>
>>> Hmm, I don't remember a bug report.
>>
>> IIRC I found a old bug report about this you fixed, but it seems it have
>> been reintroduced last time I checked, maybe it is fixed again now (I have no
>> ssh server under hand to verify right now).
>>
>>> Let's see whether I can reproduce this.
>
> Well, I've opened a remote scp connection, visiting a dired
> buffer. There, I have marked five different files (large enough). These
> files I've copied via dired-do-copy to another remote machine, also
> connected via scp. Everything works fine.

I will try again as soon as I have access to my ssh server.
Thanks.


-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]