bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Tassilo Horn]

With the current master:

emacs -Q

M-x toggle-debug-on-error
C-h f package-reinstall

You get this backtrace:

Debugger entered--Lisp error: (wrong-type-argument stringp (require . elec-pair))
  string-match("\\(\\`\\|/\\)package-x\\(\\.elc\\|\\.el\\|\\.so\\)?\\(\\.gz\\)?\\..." (require . elec-pair) nil)
  help--loaded-p("package-x")
  help--load-prefixes((("package-" "package-x" "package")))
  help--symbol-completion-table("package-reinstall" #f(compiled-function (f) #<bytecode 0x15794c0c23e9>) lambda)
  test-completion("package-reinstall" help--symbol-completion-table #f(compiled-function (f) #<bytecode 0x15794c0c23e9>))
  completion--complete-and-exit(20 37 exit-minibuffer #f(compiled-function () #<bytecode 0x15794c022699>))
  completion-complete-and-exit(20 37 exit-minibuffer)
  minibuffer-complete-and-exit()
  funcall-interactively(minibuffer-complete-and-exit)
  call-interactively(minibuffer-complete-and-exit nil nil)
  command-execute(minibuffer-complete-and-exit)
  read-from-minibuffer("Describe function: " nil (keymap (10 . minibuffer-complete-and-exit) (13 . minibuffer-complete-and-exit) keymap (menu-bar keymap (minibuf "Minibuf" keymap (tab menu-item "Complete" minibuffer-complete :help "Complete as far as possible") (space menu-item "Complete Word" minibuffer-complete-word :help "Complete at most one word") (63 menu-item "List Completions" minibuffer-completion-help :help "Display all possible completions") "Minibuf")) (27 keymap (118 . switch-to-completions)) (prior . switch-to-completions) (63 . minibuffer-completion-help) (32 . minibuffer-complete-word) (9 . minibuffer-complete) keymap (menu-bar keymap (minibuf "Minibuf" keymap (previous menu-item "Previous History Item" previous-history-element :help "Put previous minibuffer history element in the min...") (next menu-item "Next History Item" next-history-element :help "Put next minibuffer history element in the minibuf...") (isearch-backward menu-item "Isearch History Backward" isearch-backward :help "Incrementally search minibuffer history backward") (isearch-forward menu-item "Isearch History Forward" isearch-forward :help "Incrementally search minibuffer history forward") (return menu-item "Enter" exit-minibuffer :key-sequence "\15" :help "Terminate input and exit minibuffer") (quit menu-item "Quit" abort-recursive-edit :help "Abort input and exit minibuffer") "Minibuf")) (10 . exit-minibuffer) (13 . exit-minibuffer) (7 . abort-recursive-edit) (C-tab . file-cache-minibuffer-complete) (9 . self-insert-command) (XF86Back . previous-history-element) (up . previous-line-or-history-element) (prior . previous-history-element) (XF86Forward . next-history-element) (down . next-line-or-history-element) (next . next-history-element) (27 keymap (114 . previous-matching-history-element) (115 . next-matching-history-element) (112 . previous-history-element) (110 . next-history-element))) nil nil nil nil)
  completing-read-default("Describe function: " help--symbol-completion-table #f(compiled-function (f) #<bytecode 0x15794c0c23e9>) t nil nil nil nil)
  completing-read("Describe function: " help--symbol-completion-table #f(compiled-function (f) #<bytecode 0x15794c0c23e9>) t nil nil nil)
  byte-code("\301 \302\30\303\1\203\20\0\304\305\3\"\202\21\0\306\307\310\302\311\211\6\7\205\37\0\312\6\10!&\7\211\313\232\204,\0\314\1!\262\2\1\2035\0\19..." [enable-recursive-minibuffers function-called-at-point t completing-read format "Describe function (default %s): " "Describe function: " help--symbol-completion-table #f(compiled-function (f) #<bytecode 0x15794c0c23e9>) nil symbol-name "" intern user-error "You didn't specify a function symbol" fboundp function-documentation "Symbol's function definition is void: %s"] 10)
  call-interactively(describe-function nil nil)
  command-execute(describe-function)

With my normal configured emacs, I get the same error for (require
. finder-inf) at different places.

I update my master checkout almost daily.  With the version from
yesterday (around 2019-01-15 07:00 CET) I didn't have these issues.


In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.3)
 of 2019-01-16 built on pchta-and
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
System Description: Arch Linux

Recent messages:
Continuing.
file-name-sans-extension: Wrong type argument: stringp, (require . finder-inf)
Quit
Mark set
Quit
Contacting host: debbugs.gnu.org:443 [2 times]
Mark set
Mark saved where search started
Contacting host: debbugs.gnu.org:443 [6 times]
Opening nndoc server on /tmp/gnus-temp-group-azZTHY-ephemeral...done

Configured using:
 'configure --with-modules'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
NOTIFY INOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON
CANNOT_DUMP LCMS2 GMP

Important settings:
  value of $LC_MONETARY: de_DE.UTF-8
  value of $LC_NUMERIC: de_DE.UTF-8
  value of $LC_TIME: de_DE.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Help

Minor modes in effect:
  rcirc-track-minor-mode: t
  intero-global-mode: t
  global-aggressive-indent-mode: t
  recentf-mode: t
  which-key-mode: t
  beacon-mode: t
  ivy-mode: t
  global-company-mode: t
  global-magit-file-mode: t
  diff-auto-refine-mode: t
  magit-auto-revert-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  override-global-mode: t
  minibuffer-depth-indicate-mode: t
  electric-pair-mode: t
  global-subword-mode: t
  subword-mode: t
  save-place-mode: t
  savehist-mode: t
  show-paren-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  global-prettify-symbols-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 sort gnus-cite mail-extr qp gnus-async gnus-bcklg
gnus-agent gnus-srvr gnus-score score-mode nnvirtual nntp gnus-ml
gnus-msg nndoc gnus-cache gnus-dup debbugs-gnu eieio-opt speedbar
sb-image ezimage dframe tar-mode autoload lisp-mnt mm-archive url-cache
pulse misearch multi-isearch debug backtrace cus-load gnutls
network-stream rcirc-color th-private rcirc ace-window avy find-dired
the-org-mode-expansions web-mode-expansions er-basic-expansions
expand-region-core expand-region-custom grep pp cl-print help-fns
radix-tree counsel xdg swiper company-oddmuse company-keywords
company-etags company-gtags company-dabbrev-code company-dabbrev
company-files company-capf company-cmake company-xcode company-clang
company-semantic company-eclim company-template company-bbdb
highlight-symbol org-rmail org-mhe org-irc org-info org-gnus nnir
org-docview doc-view jka-compr image-mode org-bibtex bibtex org-bbdb
org-w3m paredit bug-reference generic fish-mode cargo cargo-process
markdown-mode rust-mode intero flycheck hindent haskell-mode
haskell-cabal haskell-utils haskell-font-lock haskell-indentation
haskell-string haskell-sort-imports haskell-lexeme haskell-align-imports
haskell-compat haskell-complete-module haskell-ghc-support flymake-proc
flymake etags multifile xref project compile dabbrev haskell-customize
web-mode disp-table debbugs soap-client url-http url-auth url-gw nsm
warnings rng-xsd rng-dt rng-util xsd-regexp xml aggressive-indent vc-git
vc-dir ewoc vc vc-dispatcher epa-file org-element avl-tree generator org
org-macro org-footnote org-pcomplete org-list org-faces org-entities
org-version ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob ob-table
ob-keys ob-exp ob-comint ob-core ob-eval org-compat org-macs
org-loaddefs find-func cal-menu calendar cal-loaddefs dired-x boxquote
rect smtpmail-multi smtpmail sendmail cl ecomplete yasnippet
auto-dictionary flyspell ispell tramp-sh tramp-cache tramp-rclone
recentf tree-widget which-key moody beacon highlight-parentheses smex
ido ivy delsel colir color ivy-overlay ffap thingatpt company-restclient
know-your-http-well http-status-codes http-relations http-methods
http-headers company pcase restclient noutline outline url url-proxy
url-privacy url-expand url-methods url-history url-cookie url-domsuf
url-util magit-submodule magit-obsolete magit-blame magit-stash
magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote
magit-commit magit-sequence magit-notes magit-worktree magit-tag
magit-merge magit-branch magit-reset magit-files magit-refs magit-status
magit magit-repos magit-apply magit-wip magit-log which-func imenu
magit-diff smerge-mode diff-mode magit-core magit-autorevert autorevert
filenotify magit-process magit-margin magit-mode git-commit magit-git
magit-section magit-utils magit-popup crm log-edit pcvs-util add-log
with-editor async-bytecomp async server use-package-bind-key bind-key
mb-depth rx bs windmove elec-pair cap-words superword subword saveplace
savehist paren smiley gnus-art mm-uu mml2015 mm-view mml-smime smime dig
mailcap gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap
nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range message
rmc puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader gnus-win gnus wid-edit nnheader gnus-util rmail
rmail-loaddefs rfc2047 rfc2045 ietf-drums time-date mm-util mail-prsvr
mail-utils edmacro kmacro subr-x auto-package-update easy-mmode dash
cl-extra help-mode use-package-ensure use-package-core tramp
tramp-loaddefs trampver tramp-compat ucs-normalize shell pcomplete
comint ansi-color ring parse-time format-spec advice mule-util info
finder-inf package easymenu epg-config url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json map url-vars seq byte-opt gv bytecomp byte-compile
cconv cl-loaddefs cl-lib tooltip cus-start eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type 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 elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame 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 charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 1246411 166211)
 (symbols 48 61130 10)
 (strings 32 278023 65519)
 (string-bytes 1 8499408)
 (vectors 16 111235)
 (vector-slots 8 2467707 127906)
 (floats 8 5936 1049)
 (intervals 56 44049 638)
 (buffers 992 51))
 

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Glenn Morris]

Tassilo Horn wrote:

> Debugger entered--Lisp error: (wrong-type-argument stringp (require . elec-pair))

I think this was predicted years ago in https://debbugs.gnu.org/14120 .

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Tassilo Horn]

Tassilo Horn <tsdh@gnu.org> writes:

> With the current master:
>
> emacs -Q
>
> M-x toggle-debug-on-error
> C-h f package-reinstall
>
> You get this backtrace:
>
> Debugger entered--Lisp error: (wrong-type-argument stringp (require . elec-pair))

I found the problem: the new portable dumper needs emacs.pdmp in
`data-directory'.  Unfortunately, when you run without "make install",
data-directory is set to emacs/etc/ whereas the emacs.pdmp resides in
emacs/src/.

For the time being, I've created a symlink emacs/etc/emacs.pdmp ->
emacs/src/emacs.pdmp.

Bye,
Tassilo

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Tassilo Horn]

Tassilo Horn <tsdh@gnu.org> writes:

>> With the current master:
>>
>> emacs -Q
>>
>> M-x toggle-debug-on-error
>> C-h f package-reinstall
>>
>> You get this backtrace:
>>
>> Debugger entered--Lisp error: (wrong-type-argument stringp (require . elec-pair))
>
> I found the problem: the new portable dumper needs emacs.pdmp in
> `data-directory'.  Unfortunately, when you run without "make install",
> data-directory is set to emacs/etc/ whereas the emacs.pdmp resides in
> emacs/src/.

Ah, that's not entirely true.  It seems I have to start emacs from
within the directory where the emacs.pdmp file resides.

And then I'll get an

  Fatal error 11: Segmentation faultfish: “emacs” terminated by signal SIGSEGV (Address boundary error)

but that's another story.

Bye,
Tassilo

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Robert Pluim]

Tassilo Horn <tsdh@gnu.org> writes:

> Tassilo Horn <tsdh@gnu.org> writes:
>
>> With the current master:
>>
>> emacs -Q
>>
>> M-x toggle-debug-on-error
>> C-h f package-reinstall
>>
>> You get this backtrace:
>>
>> Debugger entered--Lisp error: (wrong-type-argument stringp (require . elec-pair))
>
> I found the problem: the new portable dumper needs emacs.pdmp in
> `data-directory'.  Unfortunately, when you run without "make install",
> data-directory is set to emacs/etc/ whereas the emacs.pdmp resides in
> emacs/src/.
>

Thatʼs surprising: I haven't done 'make install', but I can't
reproduce your error.

Robert

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Tassilo Horn]

Tassilo Horn <tsdh@gnu.org> writes:

> It seems I have to start emacs from within the directory where the
> emacs.pdmp file resides.
>
> And then I'll get an
>
>   Fatal error 11: Segmentation faultfish: “emacs” terminated by signal SIGSEGV
> (Address boundary error)
>
> but that's another story.

Ok, I can reproduce the issue also at home with the current master
(8bf51c380acc04f25fba8f8aa3d1cc08b45f3e69).  When I start emacs not from
within emacs/src/, I get the original wrong-type-argument error as
described with my recipe.

One detail which might be important: I have symlinks to the emacs
executables in ~/bin/ which is on my PATH.

lrwxrwxrwx 1 horn horn   41 13. Nov 2014  ebrowse -> /home/horn/Repos/el/emacs/lib-src/ebrowse
lrwxrwxrwx 1 horn horn   35  1. Jan 2017  emacs -> /home/horn/Repos/el/emacs/src/emacs
lrwxrwxrwx 1 horn horn   45 13. Nov 2014  emacsclient -> /home/horn/Repos/el/emacs/lib-src/emacsclient
lrwxrwxrwx 1 horn horn   39 13. Nov 2014  etags -> /home/horn/Repos/el/emacs/lib-src/etags

So when I start emacs from anywhere but /home/horn/Repos/el/emacs/src/,
it'll print a lot of messages like:

Loading loadup.el (source)...
dump mode: nil
Using load-path (/usr/local/share/emacs/27.0.50/site-lisp /usr/local/share/emacs/site-lisp /home/horn/Repos/el/emacs/lisp /home/horn/Repos/el/emacs/lisp/emacs-lisp /home/horn/Repos/el/emacs/lisp/progmodes /home/horn/Repos/el/emacs/lisp/language /home/horn/Repos/el/emacs/lisp/international /home/horn/Repos/el/emacs/lisp/textmodes /home/horn/Repos/el/emacs/lisp/vc)
Loading emacs-lisp/byte-run...
Loading emacs-lisp/byte-run...done
Loading emacs-lisp/backquote...
Loading emacs-lisp/backquote...done
...

When I start it from within /home/horn/Repos/el/emacs/src/ where the
emacs executable and emacs.pdmp exists, I get no such messages.  Then,
however, I get a segfault for example when I start gnus.  Here's the
xbacktrace from gdb:

>>= gdb emacs
GNU gdb (GDB) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from emacs...done.
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
TERM = xterm-256color
Breakpoint 1 at 0x111cef: file emacs.c, line 370.
Temporary breakpoint 2 at 0x12a7f1: file sysdep.c, line 1095.
(gdb) run
Starting program: /home/horn/Repos/el/emacs/src/emacs 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffeea70700 (LWP 25211)]
[Detaching after vfork from child process 25212]
[New Thread 0x7fffee22d700 (LWP 25213)]
[New Thread 0x7fffed2b2700 (LWP 25214)]
[Detaching after vfork from child process 25215]
[Detaching after vfork from child process 25216]
[Detaching after vfork from child process 25217]
[Detaching after vfork from child process 25218]
[Detaching after vfork from child process 25219]
[Detaching after vfork from child process 25220]
[Detaching after vfork from child process 25221]
[Detaching after vfork from child process 25222]
[Detaching after vfork from child process 25223]
[Detaching after vfork from child process 25224]
[Detaching after vfork from child process 25225]
[Detaching after vfork from child process 25226]
[Detaching after vfork from child process 25227]
[Detaching after vfork from child process 25228]
[Detaching after vfork from child process 25229]
[Detaching after vfork from child process 25230]
[Detaching after vfork from child process 25231]
[Detaching after vfork from child process 25232]
[Detaching after vfork from child process 25233]
[Detaching after vfork from child process 25234]
[Detaching after vfork from child process 25235]
[Detaching after vfork from child process 25236]
[Detaching after vfork from child process 25237]
[Detaching after vfork from child process 25238]
[Detaching after vfork from child process 25246]
[Detaching after vfork from child process 25247]
[Detaching after vfork from child process 25248]
[Detaching after vfork from child process 25249]
[Detaching after vfork from child process 25250]
[Detaching after vfork from child process 25251]
[Detaching after vfork from child process 25252]
[Detaching after vfork from child process 25253]
[Detaching after vfork from child process 25254]
[Detaching after vfork from child process 25262]
[Detaching after vfork from child process 25270]
[Detaching after vfork from child process 25271]
[Detaching after vfork from child process 25272]
[Detaching after vfork from child process 25273]
[Detaching after vfork from child process 25274]
[Detaching after vfork from child process 25275]
[Detaching after vfork from child process 25276]
[Detaching after vfork from child process 25277]
[Detaching after vfork from child process 25278]
[Detaching after vfork from child process 25279]
[Detaching after vfork from child process 25280]
[Detaching after vfork from child process 25281]
[Detaching after vfork from child process 25282]
[Detaching after vfork from child process 25283]
[Detaching after vfork from child process 25284]
[Detaching after vfork from child process 25285]
[Detaching after vfork from child process 25286]
[Detaching after vfork from child process 25287]
[Detaching after vfork from child process 25288]
[Detaching after vfork from child process 25289]
[Detaching after vfork from child process 25290]
[Detaching after vfork from child process 25291]
[Detaching after vfork from child process 25292]
[Detaching after vfork from child process 25293]
[Detaching after vfork from child process 25294]
[Detaching after vfork from child process 25295]
[Detaching after vfork from child process 25296]
[Detaching after vfork from child process 25297]
[Detaching after vfork from child process 25298]
[Detaching after vfork from child process 25299]
[Detaching after vfork from child process 25300]
[Detaching after vfork from child process 25301]
[Detaching after vfork from child process 25302]
[Detaching after vfork from child process 25303]
[Detaching after vfork from child process 25304]
[Detaching after vfork from child process 25305]
[Detaching after vfork from child process 25306]
[Detaching after vfork from child process 25307]
[Detaching after vfork from child process 25308]
[Detaching after vfork from child process 25309]
[Detaching after vfork from child process 25310]
[Detaching after vfork from child process 25311]
[Detaching after vfork from child process 25312]
[Detaching after vfork from child process 25313]
[Detaching after vfork from child process 25315]
[Detaching after vfork from child process 25316]
[Detaching after vfork from child process 25317]
[Detaching after vfork from child process 25318]
[Detaching after vfork from child process 25319]
[Detaching after vfork from child process 25320]
[Detaching after vfork from child process 25321]
[Detaching after vfork from child process 25322]
[Detaching after vfork from child process 25323]
[Detaching after vfork from child process 25324]
[Detaching after vfork from child process 25325]
[Detaching after vfork from child process 25326]
[Detaching after vfork from child process 25327]
[Detaching after vfork from child process 25328]
[Detaching after vfork from child process 25329]
[Detaching after vfork from child process 25330]
[Detaching after vfork from child process 25331]
[Detaching after vfork from child process 25385]
[Detaching after vfork from child process 25386]
[Detaching after vfork from child process 25387]
[Detaching after vfork from child process 25388]
[Detaching after vfork from child process 25389]
[Detaching after vfork from child process 25390]
[Detaching after vfork from child process 25391]
[Detaching after vfork from child process 25392]
[Detaching after vfork from child process 25393]
[Detaching after vfork from child process 25401]
[Detaching after vfork from child process 25402]
[Detaching after vfork from child process 25403]
[Detaching after vfork from child process 25404]
[Detaching after vfork from child process 25405]
[Detaching after vfork from child process 25406]
[Detaching after vfork from child process 25407]
[Detaching after vfork from child process 25408]
[Detaching after vfork from child process 25409]
[Detaching after vfork from child process 25410]
[Detaching after vfork from child process 25411]
[Detaching after vfork from child process 25412]
[Detaching after vfork from child process 25420]
[Detaching after vfork from child process 25428]
[Detaching after vfork from child process 25429]
[Detaching after vfork from child process 25430]
[Detaching after vfork from child process 25431]
[Detaching after vfork from child process 25432]
[Detaching after vfork from child process 25433]
[Detaching after vfork from child process 25434]
[Detaching after vfork from child process 25435]
[Detaching after vfork from child process 25436]
[Detaching after vfork from child process 25437]
[Detaching after vfork from child process 25438]
[Detaching after vfork from child process 25439]
[Detaching after vfork from child process 25440]
[Detaching after vfork from child process 25441]
[Detaching after vfork from child process 25442]

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x000055bc33060af0 in ?? ()
(gdb) xbacktrace
"insert-file-contents" (0xffffaee8)
"eieio-persistent-read" (0xffffb178)
"gnus-registry-read" (0xffffb390)
"gnus-registry-load" (0xffffb5f0)
"gnus-registry-initialize" (0xffffb7c0)
"eval-buffer" (0xffffbab0)
"load-with-code-conversion" (0xffffbd78)
"load" (0xffffc020)
"gnus-read-init-file" (0xffffc290)
"gnus-1" (0xffffc518)
"gnus" (0xffffc820)
"funcall-interactively" (0xffffc818)
"call-interactively" (0xffffca70)
"command-execute" (0xffffcd28)
0x57ad99c0 PVEC_COMPILED
"ivy-call" (0xffffd2e8)
"ivy-read" (0xffffd870)
"counsel-M-x" (0xffffdd10)
"funcall-interactively" (0xffffdd08)
"call-interactively" (0xffffde50)
"command-execute" (0xffffe0f8)
(gdb) 

Bye,
Tassilo

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Wed, 16 Jan 2019 19:43:00 +0100
> 
> So when I start emacs from anywhere but /home/horn/Repos/el/emacs/src/,
> it'll print a lot of messages like:
> 
> Loading loadup.el (source)...
> dump mode: nil
> Using load-path (/usr/local/share/emacs/27.0.50/site-lisp /usr/local/share/emacs/site-lisp /home/horn/Repos/el/emacs/lisp /home/horn/Repos/el/emacs/lisp/emacs-lisp /home/horn/Repos/el/emacs/lisp/progmodes /home/horn/Repos/el/emacs/lisp/language /home/horn/Repos/el/emacs/lisp/international /home/horn/Repos/el/emacs/lisp/textmodes /home/horn/Repos/el/emacs/lisp/vc)
> Loading emacs-lisp/byte-run...
> Loading emacs-lisp/byte-run...done
> Loading emacs-lisp/backquote...
> Loading emacs-lisp/backquote...done
> ...

This part is expected, and is not a bug.

> When I start it from within /home/horn/Repos/el/emacs/src/ where the
> emacs executable and emacs.pdmp exists, I get no such messages.  Then,
> however, I get a segfault for example when I start gnus.  Here's the
> xbacktrace from gdb:

This is bug, of course.

> (gdb) run
> Starting program: /home/horn/Repos/el/emacs/src/emacs 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/usr/lib/libthread_db.so.1".
> [New Thread 0x7fffeea70700 (LWP 25211)]
> [Detaching after vfork from child process 25212]
> [New Thread 0x7fffee22d700 (LWP 25213)]
> [New Thread 0x7fffed2b2700 (LWP 25214)]
> [Detaching after vfork from child process 25215]
> [Detaching after vfork from child process 25216]
> [Detaching after vfork from child process 25217]
> [Detaching after vfork from child process 25218]
> [Detaching after vfork from child process 25219]

Any idea what are all those vforks about?  Is this something caused by
your init files?

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Daniel Colascione]

> Tassilo Horn <tsdh@gnu.org> writes:
>
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.

Try it now.

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Tassilo Horn]

"Daniel Colascione" <dancol@dancol.org> writes:

>> Tassilo Horn <tsdh@gnu.org> writes:
>>
>> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
>
> Try it now.

I'm now on 978cf88bda9c9b41f1cc20cf8e53a9e6caeb91be, and the crash is
gone.  Thanks a lot!

Bye,
Tassilo

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> So when I start emacs from anywhere but /home/horn/Repos/el/emacs/src/,
>> it'll print a lot of messages like:
>> 
>> Loading loadup.el (source)...
>> dump mode: nil
>> Using load-path (/usr/local/share/emacs/27.0.50/site-lisp
>> /usr/local/share/emacs/site-lisp /home/horn/Repos/el/emacs/lisp
>> /home/horn/Repos/el/emacs/lisp/emacs-lisp
>> /home/horn/Repos/el/emacs/lisp/progmodes
>> /home/horn/Repos/el/emacs/lisp/language
>> /home/horn/Repos/el/emacs/lisp/international
>> /home/horn/Repos/el/emacs/lisp/textmodes /home/horn/Repos/el/emacs/lisp/vc)
>> Loading emacs-lisp/byte-run...
>> Loading emacs-lisp/byte-run...done
>> Loading emacs-lisp/backquote...
>> Loading emacs-lisp/backquote...done
>> ...
>
> This part is expected, and is not a bug.

So with pdumper, I should always invoke ~/Repos/el/emacs/src/emacs
instead of the symlink in my PATH pointing to it?

When I start emacs using my symlink pointing to
~/Repos/el/emacs/src/emacs, I get the above output and the original
wrong-type-argument error according to my recipe.

>> When I start it from within /home/horn/Repos/el/emacs/src/ where the
>> emacs executable and emacs.pdmp exists, I get no such messages.
>> Then, however, I get a segfault for example when I start gnus.
>> Here's the xbacktrace from gdb:
>
> This is bug, of course.

Already fixed by Daniel.

>> (gdb) run
>> Starting program: /home/horn/Repos/el/emacs/src/emacs 
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/usr/lib/libthread_db.so.1".
>> [New Thread 0x7fffeea70700 (LWP 25211)]
>> [Detaching after vfork from child process 25212]
>> [New Thread 0x7fffee22d700 (LWP 25213)]
>> [New Thread 0x7fffed2b2700 (LWP 25214)]
>> [Detaching after vfork from child process 25215]
>> [Detaching after vfork from child process 25216]
>> [Detaching after vfork from child process 25217]
>> [Detaching after vfork from child process 25218]
>> [Detaching after vfork from child process 25219]
>
> Any idea what are all those vforks about?  Is this something caused by
> your init files?

I don't get them with run -Q, so I guess it's something in my init file.
When I try again, now I only get 21 vforks instead of the 132 I've had
before.

If I were keen to know what's the cause, how would I find out?

Bye,
Tassilo

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: 34094@debbugs.gnu.org
> Date: Thu, 17 Jan 2019 06:52:36 +0100
> 
> >> Using load-path (/usr/local/share/emacs/27.0.50/site-lisp
> >> /usr/local/share/emacs/site-lisp /home/horn/Repos/el/emacs/lisp
> >> /home/horn/Repos/el/emacs/lisp/emacs-lisp
> >> /home/horn/Repos/el/emacs/lisp/progmodes
> >> /home/horn/Repos/el/emacs/lisp/language
> >> /home/horn/Repos/el/emacs/lisp/international
> >> /home/horn/Repos/el/emacs/lisp/textmodes /home/horn/Repos/el/emacs/lisp/vc)
> >> Loading emacs-lisp/byte-run...
> >> Loading emacs-lisp/byte-run...done
> >> Loading emacs-lisp/backquote...
> >> Loading emacs-lisp/backquote...done
> >> ...
> >
> > This part is expected, and is not a bug.
> 
> So with pdumper, I should always invoke ~/Repos/el/emacs/src/emacs
> instead of the symlink in my PATH pointing to it?

Currently, yes.  This is how the code was written.  Whether we want to
support the symlink case is an open question, worth discussing.

> When I start emacs using my symlink pointing to
> ~/Repos/el/emacs/src/emacs, I get the above output and the original
> wrong-type-argument error according to my recipe.

To be absolutely clear: the wrong-type-argument error is also a bug,
and should be investigated.  I hope Daniel will be able to look into
that.

> >> (gdb) run
> >> Starting program: /home/horn/Repos/el/emacs/src/emacs 
> >> [Thread debugging using libthread_db enabled]
> >> Using host libthread_db library "/usr/lib/libthread_db.so.1".
> >> [New Thread 0x7fffeea70700 (LWP 25211)]
> >> [Detaching after vfork from child process 25212]
> >> [New Thread 0x7fffee22d700 (LWP 25213)]
> >> [New Thread 0x7fffed2b2700 (LWP 25214)]
> >> [Detaching after vfork from child process 25215]
> >> [Detaching after vfork from child process 25216]
> >> [Detaching after vfork from child process 25217]
> >> [Detaching after vfork from child process 25218]
> >> [Detaching after vfork from child process 25219]
> >
> > Any idea what are all those vforks about?  Is this something caused by
> > your init files?
> 
> I don't get them with run -Q, so I guess it's something in my init file.
> When I try again, now I only get 21 vforks instead of the 132 I've had
> before.
> 
> If I were keen to know what's the cause, how would I find out?

If your customizations cause a lot of processes to be launched at
startup, then the above is expected.  Otherwise, I'd suggest to look
for some code which might launch such processes which you didn't
intend.

Thanks.

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> Starting program: /home/horn/Repos/el/emacs/src/emacs 
>> >> [Thread debugging using libthread_db enabled]
>> >> Using host libthread_db library "/usr/lib/libthread_db.so.1".
>> >> [New Thread 0x7fffeea70700 (LWP 25211)]
>> >> [Detaching after vfork from child process 25212]
>> >> [New Thread 0x7fffee22d700 (LWP 25213)]
>> >> [New Thread 0x7fffed2b2700 (LWP 25214)]
>> >> [Detaching after vfork from child process 25215]
>> >> [Detaching after vfork from child process 25216]
>> >> [Detaching after vfork from child process 25217]
>> >> [Detaching after vfork from child process 25218]
>> >> [Detaching after vfork from child process 25219]
>> >
>> > Any idea what are all those vforks about?  Is this something caused
>> > by your init files?
>> 
>> I don't get them with run -Q, so I guess it's something in my init
>> file.  When I try again, now I only get 21 vforks instead of the 132
>> I've had before.
>> 
>> If I were keen to know what's the cause, how would I find out?
>
> If your customizations cause a lot of processes to be launched at
> startup, then the above is expected.  Otherwise, I'd suggest to look
> for some code which might launch such processes which you didn't
> intend.

I temporarily added

  (advice-add 'call-process :before #'debug)
  (advice-add 'start-process :before #'debug)

to my ~/.emacs and restarted, and there are several packages which
invoke external commands at startup, e.g., Magit trying to figure out
the defaults I've set in my ~/.gitconfig.  So that seems to be expected.

Bye,
Tassilo

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Daniel Colascione]

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> >> Starting program: /home/horn/Repos/el/emacs/src/emacs
>>> >> [Thread debugging using libthread_db enabled]
>>> >> Using host libthread_db library "/usr/lib/libthread_db.so.1".
>>> >> [New Thread 0x7fffeea70700 (LWP 25211)]
>>> >> [Detaching after vfork from child process 25212]
>>> >> [New Thread 0x7fffee22d700 (LWP 25213)]
>>> >> [New Thread 0x7fffed2b2700 (LWP 25214)]
>>> >> [Detaching after vfork from child process 25215]
>>> >> [Detaching after vfork from child process 25216]
>>> >> [Detaching after vfork from child process 25217]
>>> >> [Detaching after vfork from child process 25218]
>>> >> [Detaching after vfork from child process 25219]
>>> >
>>> > Any idea what are all those vforks about?  Is this something caused
>>> > by your init files?
>>>
>>> I don't get them with run -Q, so I guess it's something in my init
>>> file.  When I try again, now I only get 21 vforks instead of the 132
>>> I've had before.
>>>
>>> If I were keen to know what's the cause, how would I find out?
>>
>> If your customizations cause a lot of processes to be launched at
>> startup, then the above is expected.  Otherwise, I'd suggest to look
>> for some code which might launch such processes which you didn't
>> intend.
>
> I temporarily added
>
>   (advice-add 'call-process :before #'debug)
>   (advice-add 'start-process :before #'debug)
>
> to my ~/.emacs and restarted, and there are several packages which
> invoke external commands at startup, e.g., Magit trying to figure out
> the defaults I've set in my ~/.gitconfig.  So that seems to be expected.

IMHO, every time a package does this, it's a bug. Launching programs is
way too expensive to do on every startup. Packages should be caching the
results of system introspection somehow.

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Tassilo Horn]

"Daniel Colascione" <dancol@dancol.org> writes:

>> I temporarily added
>>
>>   (advice-add 'call-process :before #'debug)
>>   (advice-add 'start-process :before #'debug)
>>
>> to my ~/.emacs and restarted, and there are several packages which
>> invoke external commands at startup, e.g., Magit trying to figure out
>> the defaults I've set in my ~/.gitconfig.  So that seems to be expected.
>
> IMHO, every time a package does this, it's a bug. Launching programs
> is way too expensive to do on every startup. Packages should be
> caching the results of system introspection somehow.

Well, it starts up in around 3 seconds and I have 60 packages installed
(including dependencies).  And of course, I start emacs just once a day.
I can easily live with that.

Anyway, that discussion doesn't really belong here. :-)

BTW, I just compared startup times with

  time emacs --eval '(kill-emacs)'

which gave 3.2 seconds when I start emacs/src/emacs which uses the
emacs.pdmp file, and it took 4.2 seconds when I start with my symlink
where the emacs.pdmp is probably not used (Loading loadup.el (source)...
dump mode: nil).

When I do the same with -Q, it's 0.2 vs. 1.2 seconds.  So it seems like
the dump helps a lot to startup a naked emacs, but as soon as you have
your own "parallel operating system" in your ~/.emacs (and who
doesn't?), that doesn't really matter anymore.

Bye,
Tassilo

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Stefan Monnier]

> emacs -Q
>
> M-x toggle-debug-on-error
> C-h f package-reinstall
>
> You get this backtrace:
>
> Debugger entered--Lisp error: (wrong-type-argument stringp (require . elec-pair))

I'm trying to find the root cause of this messed up `load-history` but
can't reproduce this problem.  IIUC it was linked to Emacs not finding
the pdmp file, so I did

    rm src/emacs.pdmp
    emacs -Q

but that still works correctly for me.

Can anyone still reproduce such a problem with `master`?


        Stefan

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> emacs -Q
>>
>> M-x toggle-debug-on-error
>> C-h f package-reinstall
>>
>> You get this backtrace:
>>
>> Debugger entered--Lisp error: (wrong-type-argument stringp (require . elec-pair))
>
> I'm trying to find the root cause of this messed up `load-history` but
> can't reproduce this problem.  IIUC it was linked to Emacs not finding
> the pdmp file, so I did
>
>     rm src/emacs.pdmp
>     emacs -Q
>
> but that still works correctly for me.

Right, the problem back then was that I had a symlink ~/bin/emacs ->
~/Repos/el/emacs/src/emacs which didn't work with the portable dumper.

> Can anyone still reproduce such a problem with `master`?

I can't.  Back then I've replaced the above symlink with a shell
script.  Now I tried again with the symlink and my recipe doesn't
trigger the error anymore.

Bye,
Tassilo

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Stefan Monnier]

>>     rm src/emacs.pdmp
>>     emacs -Q
>>
>> but that still works correctly for me.
>
> Right, the problem back then was that I had a symlink ~/bin/emacs ->
> ~/Repos/el/emacs/src/emacs which didn't work with the portable dumper.

Right, that made the `emacs` binary fail to find the pdmp file, so
removing the pdmp file like I did above should be a good strategy to
reproduce the same problem.

> I can't.  Back then I've replaced the above symlink with a shell
> script.  Now I tried again with the symlink and my recipe doesn't
> trigger the error anymore.

There was discussion to make Emacs follow the symlink to try and find
the corresponding pdmp file, so maybe that's what you're seeing.


        Stefan

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 17 Feb 2020 11:33:30 -0500
> Cc: 34094@debbugs.gnu.org
> 
> There was discussion to make Emacs follow the symlink to try and find
> the corresponding pdmp file, so maybe that's what you're seeing.

"Discussion"?  I thought Daniel fixed that some time ago, see commit
65d45de.

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Stefan Monnier]

>> There was discussion to make Emacs follow the symlink to try and find
>> the corresponding pdmp file, so maybe that's what you're seeing.
>
> "Discussion"?  I thought Daniel fixed that some time ago, see commit
> 65d45de.

Great,  I had the impression that something had been done, but
I wasn't sure.


        Stefan

bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Xdkkz Lpwjd]

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

Here's what I get:

Case 1:
Debugger entered--Lisp error: (wrong-type-argument stringp (require . info))
  signal(wrong-type-argument (stringp (require . info)))
  #f(compiled-function (status) #<bytecode 0x1ff5ee3d21c5>)((:peer
(:certificates ...)))
  apply(#f(compiled-function (status) #<bytecode 0x1ff5ee3d21c5>) (:peer
(:certificates ((...)))))
  url-http-activate-callback()
  url-http-content-length-after-change-function(1543607 1543959 352)
  url-http-generic-filter(#<process melpa.org> "20190713 1344) ((emacs (24
4)) (cl-lib (0 5)) (avy...")

Case 2:
Debugger entered--Lisp error: (wrong-type-argument stringp (require . info))

string-match("\\(\\`\\|/\\)sendmail\\(\\.elc\\|\\.el\\|\\.so\\)?\\(\\.gz\\)?\\'"
(require . info))

load-history-filename-element("\\(\\`\\|/\\)sendmail\\(\\.elc\\|\\.el\\|\\.so\\)?\\(\\.gz\\)?\\'")
  eval-after-load("sendmail" #f(compiled-function () #<bytecode
0x1fe3afdb7e8d>))
  byte-code("\300\301\302\"\210\303\304!\207" [eval-after-load "sendmail"
#f(compiled-function () #<bytecode 0x1fe3afdb7e8d>) provide mailabbrev] 3)
  require(mailabbrev)

byte-code("\300\301!\210\300\302!\210\300\303!\210\300\304!\210\300\305!\210\300\306!\210\300\307!\210\300\310!\210\300\311!\210\300\312!\210\300\313!\210\300\314!\210\300\315..."
[require cl-lib mailheader gmm-utils mail-utils mailabbrev mail-parse mml
rfc822 format-spec dired mm-util rfc2047 puny rmc autoload
mailclient-send-it "mailclient" custom-declare-group message
((user-mail-address custom-variable) (user-full-name custom-variable))
"Mail and news message composing." :link (custom-manual "(message)Top")
:group mail news message-various nil "Various Message Variables."
(custom-manual "(message)Various Message Variables") message-buffers
"Message Buffers." (custom-manual "(message)Message Buffers")
message-sending "Message Sending." (custom-manual "(message)Sending
Variables") message-interface "Message Interface." (custom-manual
"(message)Interface") message-forwarding "Message Forwarding."
(custom-manual "(message)Forwarding") message-insertion "Message
Insertion." (custom-manual "(message)Insertion") message-headers "Message
Headers." (custom-manual "(message)Message Headers") message-news ...] 14)
  require(message)

byte-code("\300\301!\210\300\302!\210\300\303!\210\300\304!\210\305\306\307\310\311\312\311\313\314\315\316\317&\13\207"
[require add-log pcvs-util ring message custom-declare-group log-edit nil
"Major mode for editing RCS and CVS commit messages..." :group pcl-cvs vc
:version "21.1" :prefix "log-edit-"] 12)
  require(log-edit)

byte-code("\300\301!\210\300\302!\210\300\303\304\305#\210\300\306\304\305#\210\300\307!\210\300\310!\210\300\311!\210\300\312!\210\313\314\304\315\316\317\320\321\322\323&\11\210\324..."
[require dash log-edit magit-git nil t magit-utils ring server transient
with-editor custom-declare-group git-commit "Edit Git commit messages."
:prefix "git-commit-" :link (info-link "(magit)Editing Commit Messages")
:group tools custom-declare-variable global-git-commit-mode funcall
function #f(compiled-function () #<bytecode 0x1fe3b126f625>) "Non-nil if
Global Git-Commit mode is enabled.\nSee ..." :set custom-set-minor-mode
:initialize #f(compiled-function (symbol exp) #<bytecode 0x1fe3b1241291>)
:type boolean] 12)
  require(git-commit)

byte-code("\300\301!\210\300\302!\210\300\303!\210\300\304!\210\300\305!\210\300\306!\210\300\307!\210\300\310!\210\300\311!\210\300\312!\210\300\313!\210\300\314!\210\300\315..."
[require cl-lib dash subr-x with-editor git-commit magit-core magit-diff
magit-log magit-wip magit-apply magit-repos format-spec package nil t] 4)
  require(magit)

byte-code("\301\302!\210\303\304\305\306\307\310\311\312&\7\210\313\314\315\316\317DD\320\311\304\321\322&\7\210\313\323\315\316\324DD\325\326\327\311\304\321\322\330\331&\13\210\313..."
[magit-log-margin--custom-type require magit custom-declare-group
magit-status nil "Inspect and manipulate Git repositories." :link
(info-link "(magit)Status Buffer") :group magit-modes
custom-declare-variable magit-status-mode-hook funcall function
#f(compiled-function () #<bytecode 0x1fe3b01f0695>) "Hook run after
entering Magit-Status mode." :type hook magit-status-headers-hook
#f(compiled-function () #<bytecode 0x1fe3b01f06a1>) "Hook run to insert
headers into the status buffer...." :package-version (magit . "2.1.0")
:options (magit-insert-error-header magit-insert-diff-filter-header
magit-insert-repo-header magit-insert-remote-header
magit-insert-head-branch-header magit-insert-upstream-branch-header
magit-insert-push-branch-header magit-insert-tags-header)
magit-status-sections-hook #f(compiled-function () #<bytecode
0x1fe3b01f06ad>) "Hook run to insert sections into a status buffer." (magit
. "2.12.0") magit-status-initial-section #f(compiled-function () #<bytecode
0x1fe3b01f06b9>) "The section point is placed on when a status buffe..."
(magit . "2.90.0") (choice (const :tag "as usual" nil) (repeat (choice
(number :tag "nth top-level section") (sexp :tag "section identity"))))
magit-status-goto-file-position #f(compiled-function () #<bytecode
0x1fe3b00fff8d>) "Whether to go to position corresponding to file po..."
(magit . "3.0.0") boolean magit-status-show-hashes-in-headers
#f(compiled-function () #<bytecode 0x1fe3b00fff99>) "Whether headers in the
status buffer show hashes.\n..." (magit . "2.4.0") magit-status-margin
#f(compiled-function () #<bytecode 0x1fe3b00fffb1>) "Format of the margin
in `magit-status-mode' buffer..." (magit . "2.9.0") magit-margin
:initialize ...] 20)
  autoload-do-load((autoload "magit-status" "Show the status of the current
Git repository in a..." t nil) magit-status)
  command-execute(magit-status)

Case 3:
Debugger entered--Lisp error: (wrong-type-argument stringp (require .
finder-inf))

string-match("\\(\\`\\|/\\)imenu\\(\\.elc\\|\\.el\\|\\.so\\)?\\(\\.gz\\)?\\'"
(require . finder-inf))

load-history-filename-element("\\(\\`\\|/\\)imenu\\(\\.elc\\|\\.el\\|\\.so\\)?\\(\\.gz\\)?\\'")
  eval-after-load("imenu" #f(compiled-function () #<bytecode
0x1fff245b3b69>))
  require(org-compat)

byte-code("\302\303!\210\302\304!\210\302\305!\210\302\306!\210\10\307=\204:\0\3101)\0\311\312\11!\313P\314\315\211\211%0\2029\0\210\316\317!\210\320\321!\210..."
[this-command load-file-name require cl-lib calendar find-func format-spec
eval-buffer (error) load file-name-directory "org-loaddefs.el" nil t
message "WARNING: No org-loaddefs.el file could be found fr..." sit-for 3
"You need to run \"make\" or \"make autoloads\" from Or..." org-macs
org-compat org-keys ol org-table] 6)
  autoload-do-load((autoload "org" "Outline-based notes management and
organizer, alia..." t nil) org-mode)
  command-execute(org-mode record)
  execute-extended-command(nil "org-mode" "org-mode")
  funcall-interactively(execute-extended-command nil "org-mode" "org-mode")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

The way to reproduce case 3:
1. cd && mkdir backup && mv .emacs .emacs.d backup
2. add following codes to ~/.emacs

(require 'package)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)
(package-initialize)

(provide '.emacs)

3. Open emacs

  > M-x package-list-packages

  After the package list was refreshed, install yasnippet & yasnippet-snippets

  > M-x package-install ENTER yasnippet ENTER

  > M-x package-install ENTER yasnippet-snippets ENTER

4. Delete package configration from ~/.emacs, only keep this line:
   (provide '.emacs)

5. Exit emacs

6. Delete folders, only keep yasnippet-20200604.246 &
yasnippet-snippets-20200802.1658
  $ rm -rf ~/.emacs.d/auto-save-list ~/.emacs.d/elpa/archives
~/.emacs.d/elpa/gnupg ~/.emacs.d/elpa/s-20180406.808

7. Now open emacs to edit a .org file:

  $ emacs

  > C-x C-f

  > Find file: ~/ex.org Enter

8. You can see the error in minibuffer:
  File mode specification error: (wrong-type-argument stringp (require
. finder-inf))


My emacs version: GNU Emacs 27.1 (build 1, x86_64-apple-darwin18.7.0,
NS appkit-1894.60 Version 10.15.6 (Build 19G73)) of 2020-08-12

alias emacs='/Applications/Emacs.app/Contents/MacOS/Emacs -nw'

Case 3 cannot be reproduced in Emacs v26.3

Thanks

[-- Attachment #2: Type: text/html, Size: 10119 bytes --]

bug#34094: bug#34178: 27.0.50; Tramp not responding correctly to "/scp:slc:" syntax

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> There was discussion to make Emacs follow the symlink to try and find
>> the corresponding pdmp file, so maybe that's what you're seeing.
>
> "Discussion"?  I thought Daniel fixed that some time ago, see commit
> 65d45de.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I thought so, too, so I guess this bug should be fixed now, too?

Tassilo, are you still seeing this issue in recent Emacs versions?

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

bug#34178: 27.0.50; Tramp not responding correctly to "/scp:slc:" syntax

[Tassilo Horn]

Lars Ingebrigtsen <larsi@gnus.org> writes:

Hi Lars,

>>> There was discussion to make Emacs follow the symlink to try and
>>> find the corresponding pdmp file, so maybe that's what you're
>>> seeing.
>>
>> "Discussion"?  I thought Daniel fixed that some time ago, see commit
>> 65d45de.
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> I thought so, too, so I guess this bug should be fixed now, too?
>
> Tassilo, are you still seeing this issue in recent Emacs versions?

Uhm, I wonder how I got into the Cc list of that bug given that I didn't
report or comment on it.  Ah, it seems it has been merged with #34094
which I reported!

C-x C-f /scp:<host>:/... works just fine with both 28 and the current
master (-Q), so I guess the issue has been fixed.

Thanks,
Tassilo

bug#34178: 27.0.50; Tramp not responding correctly to "/scp:slc:" syntax

[Lars Ingebrigtsen]

Tassilo Horn <tsdh@gnu.org> writes:

> C-x C-f /scp:<host>:/... works just fine with both 28 and the current
> master (-Q), so I guess the issue has been fixed.

Thanks for checking; I'm closing this bug report, then.

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