GNU bug report logs -
#49261
28.0.50; File Locking Breaks Presumptuous Toolchains
Previous Next
Reported by: Mallchad Skeghyeph <ncaprisunfan <at> gmail.com>
Date: Mon, 28 Jun 2021 18:28:02 UTC
Severity: normal
Found in version 28.0.50
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 49261 in the body.
You can then email your comments to 49261 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Mon, 28 Jun 2021 18:28:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Mallchad Skeghyeph <ncaprisunfan <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 28 Jun 2021 18:28:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Date: Mon, 28 Jun 2021 18:36:19 +0100
Message-ID: <878s2tx564.fsf <at> gmail.com>
I've found for a little while now that a few default behaviors of GNU
emacs pollutes directories.
In the worst cases this can actually break programs, especially software
toolchains, where they assume a partition kind of file should be
pretend, and mistakenly tries to work with the file lock.
Another one of this files is backups and autosaves.
Ideally I would like the file lock and backup files to be placed in a
central directory,
rather than the same directory as the file in question.
After researching this problem I can see I'm not alone, and others have
felt this way for far longer than I have.
I have looked into seeing if I could change this manually,
for backups I can,
for file locks I have to dive into the source code, and after looking I
fear I would be knee deep in a very long rabbit hole without having
something more to work with.
I've not touched the source for this project before, only looked.
In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.29,
cairo version 1.17.4)
of 2021-06-20 built on m-arch-asus
Repository revision: 01b0a909b5ca858a09484821cc866127652f4153
Repository branch: makepkg
Windowing system distributor 'System Description: Arch Linux
Configured using:
'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
--localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
--with-sound=alsa --with-modules --without-gconf --without-gsettings
--with-native-compilation --with-pgtk --enable-link-time-optimization
--with-x-toolkit=gtk3 --without-xaw3d --without-m17n-flt --with-cairo
--with-xwidgets --without-compress-install 'CFLAGS=-march=x86-64
-mtune=generic -O2 -pipe -fno-plt -g -flto -fuse-linker-plugin
-fuse-ld=gold -g -flto -fuse-linker-plugin -fuse-ld=gold'
CPPFLAGS=-D_FORTIFY_SOURCE=2
LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ JPEG JSON LCMS2
LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER
PGTK PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XIM
XWIDGETS GTK3 ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Fundamental
Minor modes in effect:
company-tng-mode: t
beacon-mode: t
centaur-tabs-mode: t
global-highlight-parentheses-mode: t
smartparens-global-mode: t
smooth-scrolling-mode: t
sublimity-mode: t
global-whitespace-mode: t
global-subword-mode: t
treemacs-filewatch-mode: t
treemacs-follow-mode: t
treemacs-git-mode: deferred
treemacs-fringe-indicator-mode: t
global-hl-line-mode: t
helm-mode: t
projectile-mode: t
zoom-mode: t
ws-butler-global-mode: t
volatile-highlights-mode: t
global-undo-tree-mode: t
helm-autoresize-mode: t
helm--remap-mouse-mode: t
global-git-commit-mode: t
magit-auto-revert-mode: t
global-hungry-delete-mode: t
global-hl-todo-mode: t
recentf-mode: t
shell-dirtrack-mode: t
async-bytecomp-package-mode: t
override-global-mode: t
tooltip-mode: t
global-eldoc-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
global-visual-line-mode: t
Load-path shadows:
/home/mallchad/.emacs.d/elpa/cmake-mode-20210104.1831/cmake-mode hides
/usr/share/emacs/site-lisp/cmake-mode
/home/mallchad/.emacs.d/elpa/transient-20210525.1141/transient hides
/usr/share/emacs/28.0.50/lisp/transient
Features:
(gnus-async gnus-agent gnus-srvr gnus-score score-mode nnvirtual nntp
gnus-ml gnus-msg nndoc gnus-cache gnus-dup debbugs-gnu debbugs
soap-client rng-xsd rng-dt rng-util xsd-regexp tar-mode arc-mode
archive-mode mm-archive url-http url-gw url-cache url-auth mailclient
shadow sort mail-extr emacsbug sendmail vc bug-reference mule-util
cl-print help-fns tabify image-file image-converter magit-extras
org-indent ol-eww eww xdg url-queue mm-url ol-rmail ol-mhe ol-irc
ol-info ol-gnus nnselect gnus-search eieio-opt speedbar ezimage dframe
gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum shr kinsoku
svg 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 gnus
nnheader ol-docview doc-view jka-compr ol-bibtex bibtex ol-bbdb ol-w3m
sh-script smie executable backup-each-save cus-edit cus-start cus-load
ffap dabbrev find-file helm-command helm-elisp helm-eval edebug
backtrace lsp-diagnostics lsp-headerline lsp-icons lsp-modeline vc-git
vc-dispatcher lsp-zig lsp-steep lsp-svelte lsp-sqls lsp-yaml lsp-xml
lsp-vimscript lsp-vhdl lsp-vetur lsp-html lsp-verilog lsp-vala lsp-v
lsp-terraform lsp-tex lsp-sorbet lsp-solargraph lsp-rust lsp-rf lsp-r
lsp-purescript lsp-pylsp lsp-pyls lsp-pwsh lsp-php lsp-perl lsp-ocaml
lsp-nix lsp-nim lsp-markdown lsp-lua lsp-kotlin lsp-json lsp-javascript
lsp-haxe lsp-groovy lsp-hack lsp-go lsp-completion lsp-gdscript
lsp-fsharp lsp-fortran lsp-eslint lsp-erlang lsp-elixir lsp-elm
lsp-dockerfile lsp-dhall lsp-d lsp-css lsp-csharp lsp-crystal lsp-cmake
lsp-clojure lsp-clangd dom lsp-beancount lsp-bash lsp-angular lsp-ada
lsp-actionscript winner tramp-archive tramp-gvfs dbus helm-x-files
helm-for-files helm-bookmark helm-adaptive helm-info helm-external
helm-net xml aggressive-indent company-oddmuse company-keywords
company-etags company-gtags company-dabbrev-code company-dabbrev
company-files company-clang company-capf company-cmake company-semantic
company-template company-bbdb company-tng company rainbow-delimiters
rainbow-mode page-break-lines display-line-numbers linum init beacon
centaur-tabs centaur-tabs-interactive centaur-tabs-functions
centaur-tabs-elements powerline powerline-separators powerline-themes
highlight-parentheses smartparens-config smartparens-javascript
smartparens-rst smartparens-org smartparens-markdown smartparens-text
smartparens-c smartparens smooth-scrolling sublimity-scroll sublimity
disp-table whitespace cap-words superword subword lsp-treemacs
lsp-treemacs-themes treemacs treemacs-header-line treemacs-compatibility
treemacs-mode treemacs-bookmarks treemacs-interface treemacs-extensions
treemacs-mouse-interface treemacs-tags treemacs-persistence
treemacs-filewatch-mode treemacs-follow-mode treemacs-rendering
treemacs-async treemacs-workspaces treemacs-dom treemacs-visuals
treemacs-fringe-indicator treemacs-scope pulse treemacs-faces
treemacs-icons treemacs-themes treemacs-core-utils pfuture hl-line
treemacs-logging treemacs-customization treemacs-macros lsp-origami
lsp-ui lsp-ui-flycheck lsp-ui-doc xwidget image-mode exif magit-bookmark
bookmark goto-addr lsp-ui-imenu lsp-ui-peek lsp-ui-sideline face-remap
lsp-ui-util lsp-mode lsp-protocol spinner network-stream nsm
markdown-mode inline ewoc origami origami-parsers helm-mode helm-config
helm-swoop helm-rg pcase helm-projectile helm-files helm-tags
helm-buffers helm-occur helm-locate helm-types projectile grep ibuf-ext
ibuffer ibuffer-loaddefs helm-flycheck flycheck-inline csproj-mode
org-cliplink org-cliplink-transport org-cliplink-string em-glob esh-util
zoom ws-butler volatile-highlights visual-fill-column vlf-setup vlf
vlf-base vlf-tune visible-mark undo-tree smart-yank restart-emacs
desktop frameset rainbow-blocks org-super-agenda ts org-habit org-agenda
org-refile org-noter org-element avl-tree 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 ol org-keys org-compat org-macs
org-loaddefs cal-menu calendar cal-loaddefs omnisharp
omnisharp-unit-test-actions omnisharp-code-structure
omnisharp-server-installation gnutls omnisharp-format-actions
omnisharp-solution-actions omnisharp-helm-integration helm-grep
helm-regexp helm-utils helm-help helm helm-global-bindings helm-easymenu
helm-source helm-multi-match helm-lib omnisharp-navigation-actions
omnisharp-current-symbol-actions omnisharp-auto-complete-actions
omnisharp-server-actions omnisharp-http-utils omnisharp-utils
omnisharp-server-management omnisharp-settings f s flycheck find-func
etags fileloop generator xref project popup ido csharp-mode
csharp-compilation cc-langs json-mode json-reformat json-snatcher js
cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs multiple-cursors mc-separate-operations
rectangular-region-mode mc-mark-pop mc-edit-lines
mc-hide-unmatched-lines-mode mc-mark-more mc-cycle-cursors
multiple-cursors-core advice rect magit-submodule magit-obsolete
magit-blame magit-stash magit-reflog 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 diff-mode git-commit log-edit message rmc puny rfc822 mml mml-sec
epa derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader
pcvs-util add-log magit-core magit-autorevert autorevert filenotify
magit-margin magit-transient magit-process with-editor server magit-mode
transient magit-git magit-section magit-utils crm hydra lv hungry-delete
hl-todo god-mode free-keys fireplace dashboard dashboard-widgets time
recentf tree-widget wid-edit cmake-mode rst compile text-property-search
crux tramp tramp-loaddefs trampver tramp-integration files-x
tramp-compat shell pcomplete comint ansi-color parse-time iso8601
time-date ls-lisp format-spec thingatpt edmacro kmacro avy ring
sanityinc-tomorrow-night-theme color-theme-sanityinc-tomorrow color
all-the-icons all-the-icons-faces data-material data-weathericons
data-octicons data-fileicons data-faicons data-alltheicons
async-bytecomp async flyspell ispell req-package view req-package-cycles
req-package-args req-package-hooks ht log4e dash el-get
el-get-autoloading el-get-list-packages el-get-dependencies el-get-build
el-get-status pp el-get-methods el-get-fossil el-get-svn el-get-pacman
el-get-github-zip el-get-github-tar el-get-http-zip el-get-http-tar
el-get-hg el-get-go el-get-git-svn el-get-fink el-get-emacswiki
el-get-http el-get-notify el-get-emacsmirror el-get-github el-get-git
el-get-elpa el-get-darcs el-get-cvs el-get-bzr el-get-brew
el-get-builtin el-get-apt-get el-get-recipes el-get-byte-compile
el-get-custom el-get-core autoload radix-tree lisp-mnt dired
dired-loaddefs use-package use-package-ensure use-package-delight
use-package-diminish use-package-bind-key bind-key easy-mmode
use-package-core cl cemacs-utility finder-inf info 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 eieio
eieio-core eieio-loaddefs password-cache json map url-vars comp
comp-cstr warnings subr-x rx cl-seq cl-macs cl-extra help-mode seq
byte-opt gv cl-loaddefs cl-lib bytecomp byte-compile cconv iso-transl
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/pgtk-win pgtk-win term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-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 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
xwidget-internal dbusbind inotify dynamic-setting font-render-setting
cairo move-toolbar gtk x-toolkit pgtk lcms2 multi-tty
make-network-process native-compile emacs)
Memory information:
((conses 16 1366260 1278287)
(symbols 48 71661 1845)
(strings 32 821605 302207)
(string-bytes 1 15366299)
(vectors 16 808670)
(vector-slots 8 8340068 966354)
(floats 8 3607 3481)
(intervals 56 38157 23043)
(buffers 992 69))
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 30 Jun 2021 13:01:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Mallchad Skeghyeph <ncaprisunfan <at> gmail.com> writes:
> I've found for a little while now that a few default behaviors of GNU
> emacs pollutes directories.
Yes, this is a question that comes up from time to time, and I don't
think we've documented in a comprehensive way how to make Emacs not
write anything in the directories it visits.
For auto-save files, that's auto-save-file-name-transforms.
For backup files, that's backup-directory-alist.
For lock files, they can be switched off with create-lockfiles.
Would it make sense to allow the user to control where the lockfiles are
written? The lockfiles are symlinks, so it should theoretically be
possible to have them elsewhere without being any racier than the code
currently is, I think.
Any opinions?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 30 Jun 2021 13:27:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Wed, 30 Jun 2021 15:00:41 +0200
> Cc: 49261 <at> debbugs.gnu.org
>
> Would it make sense to allow the user to control where the lockfiles are
> written?
Yes, I think so. But it is not as trivial as it could sound,
because...
> The lockfiles are symlinks, so it should theoretically be
> possible to have them elsewhere without being any racier than the code
> currently is, I think.
...even if the lock files are symlinks (which they not necessarily
are), we need to handle the case of several files with identical
basenames in different directories. (Their being symlinks is
unimportant, because the target of the symlink doesn't exist.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 30 Jun 2021 14:09:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> The lockfiles are symlinks, so it should theoretically be
>> possible to have them elsewhere without being any racier than the code
>> currently is, I think.
>
> ...even if the lock files are symlinks (which they not necessarily
> are), we need to handle the case of several files with identical
> basenames in different directories.
We could perhaps reuse the auto-save file name logic? I.e., extend
`make-auto-save-file-name' so that we can use it to compute the lock
file names, too.
Or just use the UNIIFY logic from auto-save-file-name-transforms
unconditionally...
> (Their being symlinks is unimportant, because the target of the
> symlink doesn't exist.)
Right; I'd forgotten that we just use the lock symlink to stash some
extra data about the locking Emacs process.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 30 Jun 2021 16:08:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> Would it make sense to allow the user to control where the lockfiles are
>> written?
>
> Yes, I think so. But it is not as trivial as it could sound,
> because...
>
>> The lockfiles are symlinks, so it should theoretically be
>> possible to have them elsewhere without being any racier than the code
>> currently is, I think.
>
> ...even if the lock files are symlinks (which they not necessarily
> are), we need to handle the case of several files with identical
> basenames in different directories. (Their being symlinks is
> unimportant, because the target of the symlink doesn't exist.)
And there is the case of remote files. Do we want locking of remote
files? Should the respective lock file be local (better for performance)
or also remote (better for locking a file being accessed from different
Emacsen somewhere)?
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 30 Jun 2021 16:18:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, ncaprisunfan <at> gmail.com,
> 49261 <at> debbugs.gnu.org
> Date: Wed, 30 Jun 2021 18:07:41 +0200
>
> And there is the case of remote files. Do we want locking of remote
> files?
I think we do. maybe as an opt-in behavior?
> Should the respective lock file be local (better for performance) or
> also remote (better for locking a file being accessed from different
> Emacsen somewhere)?
Remote, I think, otherwise the lock can be easily ignored from another
machine.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 30 Jun 2021 20:05:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> For auto-save files, that's auto-save-file-name-transforms.
> For backup files, that's backup-directory-alist.
> For lock files, they can be switched off with create-lockfiles.
>
> Would it make sense to allow the user to control where the lockfiles are
> written? The lockfiles are symlinks, so it should theoretically be
> possible to have them elsewhere without being any racier than the code
> currently is, I think.
>
> Any opinions?
This is a real problem. To avoid syncing temporary files,
it's easy to add a pair of lines for every such directory:
(add-to-list 'auto-save-file-name-transforms '("\\`/dir1/dir2/.*" "/tmp/" t))
(add-to-list 'backup-directory-alist '("\\`/dir1/dir2/.*" . "/tmp/"))
Then it creates temporary files whose names contain absolute paths:
/tmp/!dir1/dir2!file~
/tmp/#!dir1/dir2!file#
But currently no way to do the same for lock files, so need to take care
not to forget to add the same pattern in every .stignore in every sync directory
to ignore lock files that is extra trouble:
.#*
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 01 Jul 2021 10:57:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 49261 <at> debbugs.gnu.org (full text, mbox):
(Please keep the debbugs address in the CCs -- otherwise the message
won't reach the bug tracker.)
Mallchad Skeghyeph <ncaprisunfan <at> gmail.com> writes:
> ...even if the lock files are symlinks (which they not necessarily
> are), we need to handle the case of several files with identical
> basenames in different directories. (Their being symlinks is
> unimportant, because the target of the symlink doesn't exist.)
>
> Actually, is there even a good reason to keep relying on symlinks in the future?
> Considering that.. ahem, some Operating Systems cannot do symlinks for the
> user?
> If it were treated as a normal file you could load it up with whatever metadata
> you want.
Using a normal file should also work, I think? But it'd be slightly
less efficient on some common popular file systems.
> Or just use the UNIIFY logic from auto-save-file-name-transforms
> unconditionally...
>
> It seems most of `make-auto-save-file-name` makes very little assumptions
> about how we're modifying the file, actually,
> so it shouldn't be too too problematic to make it work for both.
> Though, I would like an optional single variable for a directory for both,
> as oppose to a slightly opaqueregex.
>
> Remote, I think, otherwise the lock can be easily ignored from another
> machine.
>
> Yes. I think we need to keep compatibility with the current lock, if its noticed.
> Remote or local.
> In the case of remote files, we'd have to assume others might be using the
> current
> lock behaviour.
Remote files are a problem, but what to do here would be up to the user
(as it is with autosave files).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 01 Jul 2021 11:39:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Should the respective lock file be local (better for performance) or
>> also remote (better for locking a file being accessed from different
>> Emacsen somewhere)?
>
> Remote, I think, otherwise the lock can be easily ignored from another
> machine.
Auto-save files are local by default, so they have the same problem
(being ignored on other systems). However, lock files are tiny, while
auto-save files can be arbitrarily big, so from a practical point of
view there's less reason to default lock files to being local.
So I agree that having lock files being remote would be a good default.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 01 Jul 2021 12:59:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Thu, 01 Jul 2021 12:55:55 +0200
> Cc: 49261 <at> debbugs.gnu.org
>
> Mallchad Skeghyeph <ncaprisunfan <at> gmail.com> writes:
>
> > ...even if the lock files are symlinks (which they not necessarily
> > are), we need to handle the case of several files with identical
> > basenames in different directories. (Their being symlinks is
> > unimportant, because the target of the symlink doesn't exist.)
> >
> > Actually, is there even a good reason to keep relying on symlinks in the future?
> > Considering that.. ahem, some Operating Systems cannot do symlinks for the
> > user?
> > If it were treated as a normal file you could load it up with whatever metadata
> > you want.
>
> Using a normal file should also work, I think? But it'd be slightly
> less efficient on some common popular file systems.
We already use regular files on systems on which symlinks are either
unsupported or otherwise problematic.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 01 Jul 2021 16:58:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
Hi Lars,
> Yes, this is a question that comes up from time to time, and I don't
> think we've documented in a comprehensive way how to make Emacs not
> write anything in the directories it visits.
>
> For auto-save files, that's auto-save-file-name-transforms.
> For backup files, that's backup-directory-alist.
> For lock files, they can be switched off with create-lockfiles.
>
> Would it make sense to allow the user to control where the lockfiles are
> written? The lockfiles are symlinks, so it should theoretically be
> possible to have them elsewhere without being any racier than the code
> currently is, I think.
>
> Any opinions?
Thinking about, it makes much sense to write the lockfile into the same
directory as the file it locks. Think about mounted directories. If
there is, for example, an NFS server which exports home directories, and
you are editing /home/user/.emacs with different Emacs instances on
different machines, where /home/user is mounted, you want to protect
~/.emacs for write access from any Emacs instance when needed.
A similar case would be for remote files, where a file could also be
locked for access with Emacs from different machines, which use Tramp.
Note, that file lock does not exist yet for remote files, but as Eli
said, we want this feature.
So the very recommended default lock file name shall be what we have
now. We could give the user a configuration variable to change this
behaviour, but with explicit warning about consequences.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 01 Jul 2021 18:33:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Date: Thu, 01 Jul 2021 18:57:12 +0200
> Cc: Mallchad Skeghyeph <ncaprisunfan <at> gmail.com>, 49261 <at> debbugs.gnu.org
>
> So the very recommended default lock file name shall be what we have
> now. We could give the user a configuration variable to change this
> behaviour, but with explicit warning about consequences.
I think this was indeed the intent. There's no intent to change the
default behavior wrt where the lock file is written, only to introduce
a new opt-in behavior.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Fri, 02 Jul 2021 11:07:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I think this was indeed the intent. There's no intent to change the
> default behavior wrt where the lock file is written, only to introduce
> a new opt-in behavior.
Yup.
I was going to take a stab at implementing this today, but I find that I
don't have the time (probably for the next couple of days), so if
somebody else wants to take a stab at it, please be my guest. :-)
If not, I'll get to it early next week.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Fri, 02 Jul 2021 12:34:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
Hi Lars,
>> I think this was indeed the intent. There's no intent to change the
>> default behavior wrt where the lock file is written, only to introduce
>> a new opt-in behavior.
>
> I was going to take a stab at implementing this today, but I find that I
> don't have the time (probably for the next couple of days), so if
> somebody else wants to take a stab at it, please be my guest. :-)
I've pushed on my TODO to implement file locking for remote files first,
which does not exist yet. If nothing breaks my priorities, it should be
ready next days.
After that, we could see what does it need for configuration.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 16:02:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> If not, I'll get to it early next week.
Is Wednesday still "early"?
Anyway, I've now implemented this. The biggest part of this is
refactoring out the `auto-save-file-name-transforms' handling so that it
can be used by the lock handling code, too.
I'd like to have more eyes on this before I commit. It seems to work
fine after some light testing, but I'm not completely confident about
the ENCODE_FILE/ALLOCA bits in the C code.
So if somebody could give that a look-over while I'm writing up the
documentation, that'd be great. :-)
diff --git a/lisp/files.el b/lisp/files.el
index 859c193db9..ba588842a2 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -412,6 +412,21 @@ auto-save-file-name-transforms
:initialize 'custom-initialize-delay
:version "21.1")
+(defcustom lock-file-name-transforms nil
+ "Transforms to apply to buffer file name before making a lock file name.
+This has the same syntax as
+`auto-save-file-name-transforms' (which see), but instead of
+applying to auto-save file names, it's applied to lock file names.
+
+By default, a lock file is put into the same directory as the
+file it's locking, and it has the same name, but with \".#\" prepended."
+ :group 'files
+ :type '(repeat (list (regexp :tag "Regexp")
+ (string :tag "Replacement")
+ (boolean :tag "Uniquify")))
+ :initialize 'custom-initialize-delay
+ :version "28.1")
+
(defvar auto-save--timer nil "Timer for `auto-save-visited-mode'.")
(defcustom auto-save-visited-interval 5
@@ -6668,63 +6683,11 @@ make-auto-save-file-name
'make-auto-save-file-name)))
(if handler
(funcall handler 'make-auto-save-file-name)
- (let ((list auto-save-file-name-transforms)
- (filename buffer-file-name)
- result uniq)
- ;; Apply user-specified translations
- ;; to the file name.
- (while (and list (not result))
- (if (string-match (car (car list)) filename)
- (setq result (replace-match (cadr (car list)) t nil
- filename)
- uniq (car (cddr (car list)))))
- (setq list (cdr list)))
- (if result
- (setq filename
- (cond
- ((memq uniq (secure-hash-algorithms))
- (concat
- (file-name-directory result)
- (secure-hash uniq filename)))
- (uniq
- (concat
- (file-name-directory result)
- (subst-char-in-string
- ?/ ?!
- (replace-regexp-in-string
- "!" "!!" filename))))
- (t result))))
- (setq result
- (if (and (eq system-type 'ms-dos)
- (not (msdos-long-file-names)))
- ;; We truncate the file name to DOS 8+3 limits
- ;; before doing anything else, because the regexp
- ;; passed to string-match below cannot handle
- ;; extensions longer than 3 characters, multiple
- ;; dots, and other atrocities.
- (let ((fn (dos-8+3-filename
- (file-name-nondirectory buffer-file-name))))
- (string-match
- "\\`\\([^.]+\\)\\(\\.\\(..?\\)?.?\\|\\)\\'"
- fn)
- (concat (file-name-directory buffer-file-name)
- "#" (match-string 1 fn)
- "." (match-string 3 fn) "#"))
- (concat (file-name-directory filename)
- "#"
- (file-name-nondirectory filename)
- "#")))
- ;; Make sure auto-save file names don't contain characters
- ;; invalid for the underlying filesystem.
- (if (and (memq system-type '(ms-dos windows-nt cygwin))
- ;; Don't modify remote filenames
- (not (file-remote-p result)))
- (convert-standard-filename result)
- result))))
-
+ (auto-save--transform-file-name buffer-file-name
+ auto-save-file-name-transforms
+ "#" "#")))
;; Deal with buffers that don't have any associated files. (Mail
;; mode tends to create a good number of these.)
-
(let ((buffer-name (buffer-name))
(limit 0)
file-name)
@@ -6772,6 +6735,71 @@ make-auto-save-file-name
(file-error nil))
file-name)))
+(defun auto-save--transform-file-name (filename transforms
+ prefix suffix)
+ "Transform FILENAME according to TRANSFORMS.
+See `auto-save-file-name-transforms' for the format of
+TRANSFORMS. PREFIX is prepended to the non-directory portion of
+the resulting file name, and SUFFIX is appended."
+ (let (result uniq)
+ ;; Apply user-specified translations
+ ;; to the file name.
+ (while (and transforms (not result))
+ (if (string-match (car (car transforms)) filename)
+ (setq result (replace-match (cadr (car transforms)) t nil
+ filename)
+ uniq (car (cddr (car transforms)))))
+ (setq transforms (cdr transforms)))
+ (when result
+ (setq filename
+ (cond
+ ((memq uniq (secure-hash-algorithms))
+ (concat
+ (file-name-directory result)
+ (secure-hash uniq filename)))
+ (uniq
+ (concat
+ (file-name-directory result)
+ (subst-char-in-string
+ ?/ ?!
+ (replace-regexp-in-string
+ "!" "!!" filename))))
+ (t result))))
+ (setq result
+ (if (and (eq system-type 'ms-dos)
+ (not (msdos-long-file-names)))
+ ;; We truncate the file name to DOS 8+3 limits
+ ;; before doing anything else, because the regexp
+ ;; passed to string-match below cannot handle
+ ;; extensions longer than 3 characters, multiple
+ ;; dots, and other atrocities.
+ (let ((fn (dos-8+3-filename
+ (file-name-nondirectory buffer-file-name))))
+ (string-match
+ "\\`\\([^.]+\\)\\(\\.\\(..?\\)?.?\\|\\)\\'"
+ fn)
+ (concat (file-name-directory buffer-file-name)
+ prefix (match-string 1 fn)
+ "." (match-string 3 fn) suffix))
+ (concat (file-name-directory filename)
+ prefix
+ (file-name-nondirectory filename)
+ suffix)))
+ ;; Make sure auto-save file names don't contain characters
+ ;; invalid for the underlying filesystem.
+ (if (and (memq system-type '(ms-dos windows-nt cygwin))
+ ;; Don't modify remote filenames
+ (not (file-remote-p result)))
+ (convert-standard-filename result)
+ result)))
+
+(defun make-lock-file-name (filename)
+ "Make a lock file name for FILENAME.
+By default, this just prepends \".*\" to the non-directory part
+of FILENAME, but the transforms in `lock-file-name-transforms'
+are done first."
+ (auto-save--transform-file-name filename lock-file-name-transforms ".#" ""))
+
(defun auto-save-file-name-p (filename)
"Return non-nil if FILENAME can be yielded by `make-auto-save-file-name'.
FILENAME should lack slashes.
diff --git a/src/filelock.c b/src/filelock.c
index 446a262a1c..3c6e6b4942 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -294,25 +294,6 @@ get_boot_time_1 (const char *filename, bool newest)
char user[MAX_LFINFO + 1 + sizeof " (pid )" - sizeof "."];
} lock_info_type;
-/* Write the name of the lock file for FNAME into LOCKNAME. Length
- will be that of FNAME plus two more for the leading ".#", plus one
- for the null. */
-#define MAKE_LOCK_NAME(lockname, fname) \
- (lockname = SAFE_ALLOCA (SBYTES (fname) + 2 + 1), \
- fill_in_lock_file_name (lockname, fname))
-
-static void
-fill_in_lock_file_name (char *lockfile, Lisp_Object fn)
-{
- char *last_slash = memrchr (SSDATA (fn), '/', SBYTES (fn));
- char *base = last_slash + 1;
- ptrdiff_t dirlen = base - SSDATA (fn);
- memcpy (lockfile, SSDATA (fn), dirlen);
- lockfile[dirlen] = '.';
- lockfile[dirlen + 1] = '#';
- strcpy (lockfile + dirlen + 2, base);
-}
-
/* For some reason Linux kernels return EPERM on file systems that do
not support hard or symbolic links. This symbol documents the quirk.
There is no way to tell whether a symlink call fails due to
@@ -639,6 +620,12 @@ lock_if_free (lock_info_type *clasher, char *lfname)
return err;
}
+static Lisp_Object
+make_lock_file_name (Lisp_Object fn)
+{
+ return ENCODE_FILE (call1 (intern ("make-lock-file-name"), fn));
+}
+
/* lock_file locks file FN,
meaning it serves notice on the world that you intend to edit that file.
This should be done only when about to modify a file-visiting
@@ -660,10 +647,9 @@ lock_if_free (lock_info_type *clasher, char *lfname)
void
lock_file (Lisp_Object fn)
{
- Lisp_Object orig_fn, encoded_fn;
+ Lisp_Object orig_fn;
char *lfname = NULL;
lock_info_type lock_info;
- USE_SAFE_ALLOCA;
/* Don't do locking while dumping Emacs.
Uncompressing wtmp files uses call-process, which does not work
@@ -672,29 +658,25 @@ lock_file (Lisp_Object fn)
return;
orig_fn = fn;
- fn = Fexpand_file_name (fn, Qnil);
+ fn = make_lock_file_name (Fexpand_file_name (fn, Qnil));
#ifdef WINDOWSNT
/* Ensure we have only '/' separators, to avoid problems with
looking (inside fill_in_lock_file_name) for backslashes in file
names encoded by some DBCS codepage. */
dostounix_filename (SSDATA (fn));
#endif
- encoded_fn = ENCODE_FILE (fn);
- if (create_lockfiles)
- /* Create the name of the lock-file for file fn */
- MAKE_LOCK_NAME (lfname, encoded_fn);
-
+ lfname = SSDATA (fn);
/* See if this file is visited and has changed on disk since it was
visited. */
Lisp_Object subject_buf = get_truename_buffer (orig_fn);
if (!NILP (subject_buf)
&& NILP (Fverify_visited_file_modtime (subject_buf))
&& !NILP (Ffile_exists_p (fn))
- && !(lfname && current_lock_owner (NULL, lfname) == -2))
+ && !(create_lockfiles && current_lock_owner (NULL, lfname) == -2))
call1 (intern ("userlock--ask-user-about-supersession-threat"), fn);
/* Don't do locking if the user has opted out. */
- if (lfname)
+ if (create_lockfiles)
{
/* Try to lock the lock. FIXME: This ignores errors when
lock_if_free returns a positive errno value. */
@@ -715,7 +697,6 @@ lock_file (Lisp_Object fn)
if (!NILP (attack))
lock_file_1 (lfname, 1);
}
- SAFE_FREE ();
}
}
@@ -723,12 +704,9 @@ lock_file (Lisp_Object fn)
unlock_file_body (Lisp_Object fn)
{
char *lfname;
- USE_SAFE_ALLOCA;
-
- Lisp_Object filename = Fexpand_file_name (fn, Qnil);
- fn = ENCODE_FILE (filename);
- MAKE_LOCK_NAME (lfname, fn);
+ Lisp_Object filename = make_lock_file_name (Fexpand_file_name (fn, Qnil));
+ lfname = SSDATA (filename);
int err = current_lock_owner (0, lfname);
if (err == -2 && unlink (lfname) != 0 && errno != ENOENT)
@@ -736,7 +714,6 @@ unlock_file_body (Lisp_Object fn)
if (0 < err)
report_file_errno ("Unlocking file", filename, err);
- SAFE_FREE ();
return Qnil;
}
@@ -842,11 +819,10 @@ DEFUN ("file-locked-p", Ffile_locked_p, Sfile_locked_p, 1, 1, 0,
char *lfname;
int owner;
lock_info_type locker;
- USE_SAFE_ALLOCA;
filename = Fexpand_file_name (filename, Qnil);
- Lisp_Object encoded_filename = ENCODE_FILE (filename);
- MAKE_LOCK_NAME (lfname, encoded_filename);
+ Lisp_Object lockname = make_lock_file_name (filename);
+ lfname = SSDATA (lockname);
owner = current_lock_owner (&locker, lfname);
switch (owner)
@@ -857,7 +833,6 @@ DEFUN ("file-locked-p", Ffile_locked_p, Sfile_locked_p, 1, 1, 0,
default: report_file_errno ("Testing file lock", filename, owner);
}
- SAFE_FREE ();
return ret;
#endif
}
diff --git a/test/lisp/files-tests.el b/test/lisp/files-tests.el
index 257cbc2d32..b97e0256fb 100644
--- a/test/lisp/files-tests.el
+++ b/test/lisp/files-tests.el
@@ -949,6 +949,44 @@ files-tests-file-name-non-special-make-auto-save-file-name
(make-auto-save-file-name)
(kill-buffer)))))))
+(ert-deftest files-test-auto-save-name-default ()
+ (with-temp-buffer
+ (let ((auto-save-file-name-transforms nil))
+ (setq buffer-file-name "/tmp/foo.txt")
+ (should (equal (make-auto-save-file-name) "/tmp/#foo.txt#")))))
+
+(ert-deftest files-test-auto-save-name-transform ()
+ (with-temp-buffer
+ (setq buffer-file-name "/tmp/foo.txt")
+ (let ((auto-save-file-name-transforms
+ '(("\\`/.*/\\([^/]+\\)\\'" "/var/tmp/\\1" nil))))
+ (should (equal (make-auto-save-file-name) "/var/tmp/#foo.txt#")))))
+
+(ert-deftest files-test-auto-save-name-unique ()
+ (with-temp-buffer
+ (setq buffer-file-name "/tmp/foo.txt")
+ (let ((auto-save-file-name-transforms
+ '(("\\`/.*/\\([^/]+\\)\\'" "/var/tmp/\\1" t))))
+ (should (equal (make-auto-save-file-name) "/var/tmp/#!tmp!foo.txt#")))
+ (let ((auto-save-file-name-transforms
+ '(("\\`/.*/\\([^/]+\\)\\'" "/var/tmp/\\1" sha1))))
+ (should (equal (make-auto-save-file-name)
+ "/var/tmp/#b57c5a04f429a83305859d3350ecdab8315a9037#")))))
+
+(ert-deftest files-test-lock-name-default ()
+ (let ((lock-file-name-transforms nil))
+ (should (equal (make-lock-file-name "/tmp/foo.txt") "/tmp/.#foo.txt"))))
+
+(ert-deftest files-test-lock-name-unique ()
+ (let ((lock-file-name-transforms
+ '(("\\`/.*/\\([^/]+\\)\\'" "/var/tmp/\\1" t))))
+ (should (equal (make-lock-file-name "/tmp/foo.txt")
+ "/var/tmp/.#!tmp!foo.txt")))
+ (let ((lock-file-name-transforms
+ '(("\\`/.*/\\([^/]+\\)\\'" "/var/tmp/\\1" sha1))))
+ (should (equal (make-lock-file-name "/tmp/foo.txt")
+ "/var/tmp/.#b57c5a04f429a83305859d3350ecdab8315a9037"))))
+
(ert-deftest files-tests-file-name-non-special-make-directory ()
(files-tests--with-temp-non-special (tmpdir nospecial-dir t)
(let ((default-directory nospecial-dir))
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 16:08:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> If not, I'll get to it early next week.
>
> Is Wednesday still "early"?
Uuhh, I'm almost finished. I'm running some final tests, my plan is to
commit tonight.
Would it be OK for you? I promise, I will check your patch immediately
after this.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 16:14:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> Uuhh, I'm almost finished. I'm running some final tests, my plan is to
> commit tonight.
>
> Would it be OK for you? I promise, I will check your patch immediately
> after this.
Sure. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 16:42:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>> Uuhh, I'm almost finished. I'm running some final tests, my plan is to
>> commit tonight.
>>
>> Would it be OK for you? I promise, I will check your patch immediately
>> after this.
>
> Sure. :-)
There are still two failed test cases. But I guess it will be better to
hunt them together with your applied patch.
I've committed my work as d35868bec9. Go on and push your changes, and
let's puzzle the final bits afterwards.
(Ohh, Glenn will beat me)
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 16:56:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
Hi Lars,
> So if somebody could give that a look-over while I'm writing up the
> documentation, that'd be great. :-)
Just some first thoughts, by dry reading.
> (if handler
> (funcall handler 'make-auto-save-file-name)
We have a file name handler for make-auto-save-file-name. Shall we use
also a handler for make-lock-file-name?
> +(defun make-lock-file-name (filename)
> + "Make a lock file name for FILENAME.
> +By default, this just prepends \".*\" to the non-directory part
> +of FILENAME, but the transforms in `lock-file-name-transforms'
> +are done first."
> + (auto-save--transform-file-name filename lock-file-name-transforms ".#" ""))
Hmm, maybe not, because the lock file name must be the *same* over
different Emacs sessions.
Furthermore, there is auto-save-mode, which toggles auto-saving. Shall
we use something similar for file locks? Perhaps, people might not want
to lock all files, for example they might want to disable this feature
for remote files (possible performance degradation).
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 16:59:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> There are still two failed test cases. But I guess it will be better to
> hunt them together with your applied patch.
>
> I've committed my work as d35868bec9. Go on and push your changes, and
> let's puzzle the final bits afterwards.
I have some errands to run, so I'm not pushing right away -- but I'll do
so later tonight, unless I discover major problems...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 17:01:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> Just some first thoughts, by dry reading.
>
>> (if handler
>> (funcall handler 'make-auto-save-file-name)
>
> We have a file name handler for make-auto-save-file-name. Shall we use
> also a handler for make-lock-file-name?
Yeah, I wondered about that, too. I'm not quite sure what the use case
would be, but for symmetry's sake, it might make sense anyway.
>> +(defun make-lock-file-name (filename)
>> + "Make a lock file name for FILENAME.
>> +By default, this just prepends \".*\" to the non-directory part
>> +of FILENAME, but the transforms in `lock-file-name-transforms'
>> +are done first."
>> + (auto-save--transform-file-name filename lock-file-name-transforms
>> ".#" ""))
>
> Hmm, maybe not, because the lock file name must be the *same* over
> different Emacs sessions.
That would be up to the person that writes the handler to take care of,
I think?
> Furthermore, there is auto-save-mode, which toggles auto-saving. Shall
> we use something similar for file locks? Perhaps, people might not want
> to lock all files, for example they might want to disable this feature
> for remote files (possible performance degradation).
Sure; makes sense.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 17:37:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>>> (if handler
>>> (funcall handler 'make-auto-save-file-name)
>>
>> We have a file name handler for make-auto-save-file-name. Shall we use
>> also a handler for make-lock-file-name?
>
> Yeah, I wondered about that, too. I'm not quite sure what the use case
> would be, but for symmetry's sake, it might make sense anyway.
OK, I'll care.
One use case could be a file lock for a file archive (something like
foo.tar), when you change a file inside the archive.
>> Hmm, maybe not, because the lock file name must be the *same* over
>> different Emacs sessions.
>
> That would be up to the person that writes the handler to take care of,
> I think?
:-)
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 18:03:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Michael Albinus <michael.albinus <at> gmx.de>, ncaprisunfan <at> gmail.com,
> 49261 <at> debbugs.gnu.org
> Date: Wed, 07 Jul 2021 18:01:25 +0200
>
> +(defun auto-save--transform-file-name (filename transforms
> + prefix suffix)
> + "Transform FILENAME according to TRANSFORMS.
> +See `auto-save-file-name-transforms' for the format of
> +TRANSFORMS. PREFIX is prepended to the non-directory portion of
> +the resulting file name, and SUFFIX is appended."
> + (let (result uniq)
> + ;; Apply user-specified translations
> + ;; to the file name.
> + (while (and transforms (not result))
> + (if (string-match (car (car transforms)) filename)
> + (setq result (replace-match (cadr (car transforms)) t nil
> + filename)
> + uniq (car (cddr (car transforms)))))
If this is going to be called from C, it should probably use
save-match-data, because no one will expect that just modifying a file
from some Lisp program could clobber the match data.
Also, do we ever need this during loadup? Because before files.el is
loaded by loadup, this function will not be available, so
unconditionally calling it from C without protection, not even
safe_call or somesuch, is not safe.
> +static Lisp_Object
> +make_lock_file_name (Lisp_Object fn)
> +{
> + return ENCODE_FILE (call1 (intern ("make-lock-file-name"), fn));
> +}
I'd prefer not to have a function return an encoded file name, it's
unusual and unexpected. It is better to leave that to the caller.
(And if you do that, the rationale for having a separate function for
this will all but disappear, I think.)
> - fn = Fexpand_file_name (fn, Qnil);
> + fn = make_lock_file_name (Fexpand_file_name (fn, Qnil));
In the original code, 'fn' was an un-encoded file name, but your
changes made it encoded. Why not keep the code more similar by having
a separate variable with the encoded file name? E.g., this would
avoid potential trouble here:
> if (!NILP (subject_buf)
> && NILP (Fverify_visited_file_modtime (subject_buf))
> && !NILP (Ffile_exists_p (fn)) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Ffile_exists_p was passed an un-encoded file name in the original
code. It calls file handlers, and encodes local file names by itself,
so it is better to pass it un-encoded file names.
> - && !(lfname && current_lock_owner (NULL, lfname) == -2))
> + && !(create_lockfiles && current_lock_owner (NULL, lfname) == -2))
> call1 (intern ("userlock--ask-user-about-supersession-threat"), fn);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Likewise here: Lisp function should generally be called with
un-encoded file names.
> unlock_file_body (Lisp_Object fn)
> {
> char *lfname;
> - USE_SAFE_ALLOCA;
> -
> - Lisp_Object filename = Fexpand_file_name (fn, Qnil);
> - fn = ENCODE_FILE (filename);
>
> - MAKE_LOCK_NAME (lfname, fn);
> + Lisp_Object filename = make_lock_file_name (Fexpand_file_name (fn, Qnil));
> + lfname = SSDATA (filename);
>
> int err = current_lock_owner (0, lfname);
> if (err == -2 && unlink (lfname) != 0 && errno != ENOENT)
> @@ -736,7 +714,6 @@ unlock_file_body (Lisp_Object fn)
> if (0 < err)
> report_file_errno ("Unlocking file", filename, err);
Same problem here: 'filename' is now an encoded file name, so you call
report_file_errno with an encoded file name, which is a no-no.
Last, but not least: do we care that now locking a file will cons
strings, even with the default value of lock-file-name-transforms?
That sounds like we are punishing the vast majority of users for the
benefit of the few who need the opt-in behavior. Should we perhaps
avoid consing strings, or maybe even calling Lisp altogether, under
the default value of that option?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 18:10:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 49261 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
While looking at this code, I'm puzzled by:
- orig_fn = fn;
- fn = Fexpand_file_name (fn, Qnil);
-#ifdef WINDOWSNT
- /* Ensure we have only '/' separators, to avoid problems with
- looking (inside fill_in_lock_file_name) for backslashes in file
- names encoded by some DBCS codepage. */
- dostounix_filename (SSDATA (fn));
-#endif
- encoded_fn = ENCODE_FILE (fn);
- if (create_lockfiles)
- /* Create the name of the lock-file for file fn */
- MAKE_LOCK_NAME (lfname, encoded_fn);
-
So here we (possibly destructively) alter the data in the fn string on
WINDOWSNT, because we want to avoid problems in fill_in_lock_file_name.
OK, but we call MAKE_LOCK_NAME (which calls fill_in_lock_file_name) in
two other places, and in those places the call isn't guarded by a call
to dostounix_filename.
This is moot after my patch, since MAKE_LOCK_NAME is gone, but I'm still
worried that there's something I don't understand here... The
dostounix_filename call was added by Eli in 2013.
So I think I'll wait to push this patch until Eli has given it a
once-over. I've included the current state of the patch below as an
attachment.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
[lock.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 18:18:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> If this is going to be called from C, it should probably use
> save-match-data, because no one will expect that just modifying a file
> from some Lisp program could clobber the match data.
Right; now added.
> Also, do we ever need this during loadup? Because before files.el is
> loaded by loadup, this function will not be available, so
> unconditionally calling it from C without protection, not even
> safe_call or somesuch, is not safe.
I'll try doing a "make bootstrap"...
>> +static Lisp_Object
>> +make_lock_file_name (Lisp_Object fn)
>> +{
>> + return ENCODE_FILE (call1 (intern ("make-lock-file-name"), fn));
>> +}
>
> I'd prefer not to have a function return an encoded file name, it's
> unusual and unexpected. It is better to leave that to the caller.
> (And if you do that, the rationale for having a separate function for
> this will all but disappear, I think.)
Right. But it seemed like all the callers wanted an encoded file name
here, so it was marginally cleaner.
>> - fn = Fexpand_file_name (fn, Qnil);
>> + fn = make_lock_file_name (Fexpand_file_name (fn, Qnil));
>
> In the original code, 'fn' was an un-encoded file name, but your
> changes made it encoded. Why not keep the code more similar by having
> a separate variable with the encoded file name? E.g., this would
> avoid potential trouble here:
Yup; I've now rewritten this to not reuse variables in this way, because
it was pretty confusing. (See the version of the patch I posted some
minutes ago.)
>> if (!NILP (subject_buf)
>> && NILP (Fverify_visited_file_modtime (subject_buf))
>> && !NILP (Ffile_exists_p (fn)) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> Ffile_exists_p was passed an un-encoded file name in the original
> code. It calls file handlers, and encodes local file names by itself,
> so it is better to pass it un-encoded file names.
[...]
> Same problem here: 'filename' is now an encoded file name, so you call
> report_file_errno with an encoded file name, which is a no-no.
Right; I'll fix up the un-encoded/encoded file name confusion here.
> Last, but not least: do we care that now locking a file will cons
> strings, even with the default value of lock-file-name-transforms?
> That sounds like we are punishing the vast majority of users for the
> benefit of the few who need the opt-in behavior. Should we perhaps
> avoid consing strings, or maybe even calling Lisp altogether, under
> the default value of that option?
Hm... I think for simplicity's sake, it makes sense to always call the
Lisp code. Having two places where we insert ".#" into a file name just
seems error prone, long term.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 18:21:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>> Also, do we ever need this during loadup? Because before files.el is
>> loaded by loadup, this function will not be available, so
>> unconditionally calling it from C without protection, not even
>> safe_call or somesuch, is not safe.
>
> I'll try doing a "make bootstrap"...
And that's finished now, and went without a hitch with the new patch.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 18:34:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, ncaprisunfan <at> gmail.com,
> 49261 <at> debbugs.gnu.org
> Date: Wed, 07 Jul 2021 20:08:48 +0200
>
> While looking at this code, I'm puzzled by:
>
> - orig_fn = fn;
> - fn = Fexpand_file_name (fn, Qnil);
> -#ifdef WINDOWSNT
> - /* Ensure we have only '/' separators, to avoid problems with
> - looking (inside fill_in_lock_file_name) for backslashes in file
> - names encoded by some DBCS codepage. */
> - dostounix_filename (SSDATA (fn));
> -#endif
> - encoded_fn = ENCODE_FILE (fn);
> - if (create_lockfiles)
> - /* Create the name of the lock-file for file fn */
> - MAKE_LOCK_NAME (lfname, encoded_fn);
> -
>
> So here we (possibly destructively) alter the data in the fn string on
> WINDOWSNT, because we want to avoid problems in fill_in_lock_file_name.
> OK, but we call MAKE_LOCK_NAME (which calls fill_in_lock_file_name) in
> two other places, and in those places the call isn't guarded by a call
> to dostounix_filename.
>
> This is moot after my patch, since MAKE_LOCK_NAME is gone, but I'm still
> worried that there's something I don't understand here... The
> dostounix_filename call was added by Eli in 2013.
It's a bug. Or maybe it was a bug, back then, because I think
nowadays expand-file-name always converts backslashes to forward
slashes. And actually the fact that MAKE_LOCK_NAME looks for slashes
in encoded file names is also a subtle bug (or at least unsafe code):
some coding-systems don't guarantee that a '/' byte can never be part
of a multibyte sequence.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 18:43:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: michael.albinus <at> gmx.de, ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org
> Date: Wed, 07 Jul 2021 20:17:22 +0200
>
> > Also, do we ever need this during loadup? Because before files.el is
> > loaded by loadup, this function will not be available, so
> > unconditionally calling it from C without protection, not even
> > safe_call or somesuch, is not safe.
>
> I'll try doing a "make bootstrap"...
Even if it currently works, it's unsafe, IMO, to not have any
protection there. No one will remember that we rely on this not being
called early enough.
> > Last, but not least: do we care that now locking a file will cons
> > strings, even with the default value of lock-file-name-transforms?
> > That sounds like we are punishing the vast majority of users for the
> > benefit of the few who need the opt-in behavior. Should we perhaps
> > avoid consing strings, or maybe even calling Lisp altogether, under
> > the default value of that option?
>
> Hm... I think for simplicity's sake, it makes sense to always call the
> Lisp code. Having two places where we insert ".#" into a file name just
> seems error prone, long term.
My point is that this simplicity comes at a price. We've been
consistently moving code from C primitives to Lisp, and by doing that
significantly increase the consing during even the simplest editing
operations. All this consing adds up, with the result that Emacs
nowadays produces much more garbage, which then triggers frequent GC
cycles, which slow down Emacs. It's a small wonder we see so many
people out there raising the GC threshold to dangerous levels.
So I'm asking whether the simplicity justifies the costs, here and
elsewhere.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 18:51:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> It's a bug. Or maybe it was a bug, back then, because I think
> nowadays expand-file-name always converts backslashes to forward
> slashes. And actually the fact that MAKE_LOCK_NAME looks for slashes
> in encoded file names is also a subtle bug (or at least unsafe code):
> some coding-systems don't guarantee that a '/' byte can never be part
> of a multibyte sequence.
Ah, cool, then I wasn't totally misreading the code. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 18:51:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: michael.albinus <at> gmx.de, ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org
> Date: Wed, 07 Jul 2021 20:17:22 +0200
>
> Hm... I think for simplicity's sake, it makes sense to always call the
> Lisp code. Having two places where we insert ".#" into a file name just
> seems error prone, long term.
Btw, we could avoid having 2 places that produces the default
".#"+FILENAME lock file name by exposing to Lisp a C primitive which
does that. So that problem can easily be solved.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 18:59:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Even if it currently works, it's unsafe, IMO, to not have any
> protection there. No one will remember that we rely on this not being
> called early enough.
Right. My reasoning was that it seemed unlikely to be a problem here,
since the same function also (possibly) calls the Lisp functions
userlock--ask-user-about-supersession-threat and ask-user-about-lock.
But those are only called in some cases, so we're calling out to Lisp
more now than before, and that may indeed be a problem.
I can add a check to whether the Lisp function is defined before calling
(and then not do locking if it isn't) to be more defensive here?
> My point is that this simplicity comes at a price. We've been
> consistently moving code from C primitives to Lisp, and by doing that
> significantly increase the consing during even the simplest editing
> operations. All this consing adds up, with the result that Emacs
> nowadays produces much more garbage, which then triggers frequent GC
> cycles, which slow down Emacs. It's a small wonder we see so many
> people out there raising the GC threshold to dangerous levels.
>
> So I'm asking whether the simplicity justifies the costs, here and
> elsewhere.
I agree with you 100% that it's important to take this into
consideration when moving things from C to Lisp. In this particular
case, I think the cost is justified, because this isn't a function
that's called in a loop, and the other things it does (calling
Fverify_visited_file_modtime and Ffile_exists_p, and actually creating
the lock file) totally swamps any extra string consing, I think. (That
is, it won't take measurably longer.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 19:04:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> I can add a check to whether the Lisp function is defined before calling
> (and then not do locking if it isn't) to be more defensive here?
Ah, I didn't notice that lock_file starts like this:
/* Don't do locking while dumping Emacs.
Uncompressing wtmp files uses call-process, which does not work
in an uninitialized Emacs. */
if (will_dump_p ())
return;
So I think we're basically safe...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 19:21:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: michael.albinus <at> gmx.de, ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org
> Date: Wed, 07 Jul 2021 20:58:29 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Even if it currently works, it's unsafe, IMO, to not have any
> > protection there. No one will remember that we rely on this not being
> > called early enough.
>
> Right. My reasoning was that it seemed unlikely to be a problem here,
> since the same function also (possibly) calls the Lisp functions
> userlock--ask-user-about-supersession-threat and ask-user-about-lock.
> But those are only called in some cases, so we're calling out to Lisp
> more now than before, and that may indeed be a problem.
Right, the call to userlock--ask-user-about-supersession-threat is
under some conditions that are rarely satisfied.
> I can add a check to whether the Lisp function is defined before calling
> (and then not do locking if it isn't) to be more defensive here?
I guess so.
> > So I'm asking whether the simplicity justifies the costs, here and
> > elsewhere.
>
> I agree with you 100% that it's important to take this into
> consideration when moving things from C to Lisp. In this particular
> case, I think the cost is justified, because this isn't a function
> that's called in a loop, and the other things it does (calling
> Fverify_visited_file_modtime and Ffile_exists_p, and actually creating
> the lock file) totally swamps any extra string consing, I think. (That
> is, it won't take measurably longer.)
If it triggers GC, it _will_ take significantly longer. But I won't
argue more about this, it's a lost battle anyway with current Emacs
development trends.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 19:23:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Btw, we could avoid having 2 places that produces the default
> ".#"+FILENAME lock file name by exposing to Lisp a C primitive which
> does that. So that problem can easily be solved.
Yes, that's definitely true. We could even make it more general and
then use it, for instance, in the auto-save code path, too.
That is, with a signature of, say...
(file-name-surround file-name prefix &optional suffix)
(file-name-surround "/tmp/foo.txt" "#" "#")
=> "/tmp/#foo.txt#"
It'd be less consing than the current
(concat (file-name-directory filename) "#" (file-name-nondirectory filename) "#")
code we have.
A better name would be nice, though. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 19:41:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 49261 <at> debbugs.gnu.org (full text, mbox):
I've now pushed this change. Michael, there were some conflicts in
filelock.c with your changes from earlier this evening -- can you check
whether I resolved them correctly?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 20:04:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
Hi Lars,
> I've now pushed this change. Michael, there were some conflicts in
> filelock.c with your changes from earlier this evening -- can you check
> whether I resolved them correctly?
I see no regressions. Three test cases still fail
(file-notify-test03-events-remote, shadow-test08-shadow-todo,
shadow-test09-shadow-copy-files), but the most important one,
tramp-test39-lock-file, still succeeds.
I will check tomorrow why these test cases fail, and how to integrate
the new lock-file-name-transforms into Tramp.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 20:06:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, ncaprisunfan <at> gmail.com,
> 49261 <at> debbugs.gnu.org
> Date: Wed, 07 Jul 2021 21:40:34 +0200
>
> I've now pushed this change.
The build seems to be broken:
Finding pointers to doc strings...done
SCRAPE ./calendar
Debugger entered--Lisp error: (void-function make-lock-file-name)
make-lock-file-name("/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda...")
insert-file-contents("/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda..." t)
find-file-noselect-1(#<buffer cal-loaddefs.el> "/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda..." nil nil "/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda..." (51128996 64768))
find-file-noselect("/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda...")
autoload-find-generated-file("/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda...")
make-directory-autoloads(("./calendar") "/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda...")
batch-update-autoloads()
command-line-1(("-l" "autoload" "--eval" "(setq generate-autoload-cookie \";;;###cal-autoload..." "--eval" "(setq generated-autoload-file (expand-file-name (u..." "-f" "batch-update-autoloads" "./calendar"))
command-line()
normal-top-level()
eval((normal-top-level) t)
load("loadup.el")
make[2]: *** [calendar/cal-loaddefs.el] Error 255
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 20:11:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> The build seems to be broken:
>
> Finding pointers to doc strings...done
> SCRAPE ./calendar
> Debugger entered--Lisp error: (void-function make-lock-file-name)
> make-lock-file-name("/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda...")
> insert-file-contents("/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda..." t)
And I'm seeing a segfault, too, ending with:
Loading /home/larsi/src/emacs/trunk/lisp/cus-face.el (source)...
Loading /home/larsi/src/emacs/trunk/lisp/faces.el (source)...
Fatal error 11: Segmentation fault
I'm investigating.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 20:11:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 07 Jul 2021 23:05:33 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: michael.albinus <at> gmx.de, ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org
>
> > From: Lars Ingebrigtsen <larsi <at> gnus.org>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, ncaprisunfan <at> gmail.com,
> > 49261 <at> debbugs.gnu.org
> > Date: Wed, 07 Jul 2021 21:40:34 +0200
> >
> > I've now pushed this change.
>
> The build seems to be broken:
Sorry, that was my fault.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 20:16:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: michael.albinus <at> gmx.de, ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org
> Date: Wed, 07 Jul 2021 22:09:53 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > The build seems to be broken:
> >
> > Finding pointers to doc strings...done
> > SCRAPE ./calendar
> > Debugger entered--Lisp error: (void-function make-lock-file-name)
> > make-lock-file-name("/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda...")
> > insert-file-contents("/srv/data/home/e/eliz/git/emacs/trunk/lisp/calenda..." t)
>
> And I'm seeing a segfault, too, ending with:
>
> Loading /home/larsi/src/emacs/trunk/lisp/cus-face.el (source)...
> Loading /home/larsi/src/emacs/trunk/lisp/faces.el (source)...
> Fatal error 11: Segmentation fault
My stupid typo, should be fixed now.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 20:20:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> The build seems to be broken:
>
> Sorry, that was my fault.
You were right that we needed to make the call-out to Lisp more robust,
so I pushed a change that checks whether the function is defined before
calling it.
After your faces.el fix and that additional check, Emacs now builds for
me again, both incremental and bootstrap.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 20:30:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> After your faces.el fix and that additional check, Emacs now builds for
> me again, both incremental and bootstrap.
Or... did I speak too soon? It builds fine on Debian and Windows
(incrementally and bootstrap), but I'm getting this on Macos:
Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../admin/grammars all EMACS="../../src/bootstrap-emacs"
make[3]: Nothing to be done for `all'.
GEN loaddefs.el
/bin/sh: line 1: 51261 Killed: 9 EMACSLOADPATH= '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp -l autoload --eval '(setq autoload-ensure-writable t)' --eval '(setq autoload-builtin-package-versions t)' --eval '(setq generated-autoload-file (expand-file-name (unmsys--file-name "loaddefs.el")))' -f batch-update-autoloads . ./calc ./calendar ./cedet ./cedet/ede ./cedet/semantic ./cedet/semantic/analyze ./cedet/semantic/bovine ./cedet/semantic/decorate ./cedet/semantic/symref ./cedet/semantic/wisent ./cedet/srecode ./emacs-lisp ./emulation ./erc ./eshell ./gnus ./image ./international ./language ./leim ./leim/ja-dic ./leim/quail ./mail ./mh-e ./net ./nxml ./org ./play ./progmodes ./textmodes ./url ./vc
make[2]: *** [loaddefs.el] Error 137
make[1]: *** [../lisp/loaddefs.el] Error 2
make: *** [src] Error 2
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 20:39:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Or... did I speak too soon? It builds fine on Debian and Windows
> (incrementally and bootstrap), but I'm getting this on Macos:
Ah, I'm seeing it elsewhere too when saying "touch lisp/*.el":
make[2]: *** [Makefile:279: ../lisp/cus-start.elc] Error 139
make[1]: *** [Makefile:765: ../lisp/cus-start.elc] Error 2
/bin/sh: line 2: 113032 Segmentation fault (core dumped) EMACSLOADPATH= '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -l bytecomp -f byte-compile-refresh-preloaded -f batch-byte-compile ../lisp/button.el
make[2]: *** [Makefile:279: ../lisp/button.elc] Error 139
make[1]: *** [Makefile:765: ../lisp/button.elc] Error 2
/bin/sh: line 2: 113024 Segmentation fault (core dumped) EMACSLOADPATH= '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -l bytecomp -f byte-compile-refresh-preloaded -f batch-byte-compile ../lisp/abbrev.el
Still investigating... perhaps I got the lifecycle of a variable wrong
or something?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 20:56:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Still investigating... perhaps I got the lifecycle of a variable wrong
> or something?
It only happens with an -O2 build -- an -O0 build works fine. Here's
what gdb says:
#0 0x00005555557103a7 in AREF (idx=23456123314108, array=0x7ffff1a398cd)
at lisp.h:731
#1 HASH_KEY (idx=11728061657054, h=0x7ffff1a39848) at lisp.h:2374
#2 hash_lookup (h=0x7ffff1a39848, key=0x555555cae444, hash=hash <at> entry=0x0)
at fns.c:4479
#3 0x000055555573f9f2 in exec_byte_code
(bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
at bytecode.c:1415
#4 0x0000555555701d07 in Ffuncall (nargs=2, args=args <at> entry=0x7fffffffcec8)
at eval.c:3055
#5 0x000055555573d1c8 in exec_byte_code
(bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
at bytecode.c:632
#6 0x0000555555701d07 in Ffuncall (nargs=1, args=args <at> entry=0x7fffffffd790)
at eval.c:3055
#7 0x000055555573d1c8 in exec_byte_code
(bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
at bytecode.c:632
#8 0x000055555570502f in apply_lambda
(fun=0x7ffff1a23485, args=<optimized out>, count=4) at eval.c:3188
#9 0x00005555557040b3 in eval_sub (form=<optimized out>) at eval.c:2591
#10 0x0000555555705cd9 in Feval (form=0x7ffff1fc6b23, lexical=<optimized out>)
at eval.c:2343
#11 0x0000555555700da7 in internal_condition_case
(bfun=bfun <at> entry=0x5555556872a0 <top_level_2>, handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x55555568ccf0 <cmd_error>) at eval.c:1478
#12 0x0000555555687f26 in top_level_1 (ignore=ignore <at> entry=0x0)
at keyboard.c:1111
#13 0x00005555557032a3 in internal_catch
(tag=tag <at> entry=0xe610, func=func <at> entry=0x555555687f00 <top_level_1>, arg=arg <at> entry=0x0) at eval.c:1198
#14 0x0000555555687228 in command_loop () at lisp.h:1002
#15 0x000055555568c906 in recursive_edit_1 () at keyboard.c:720
#16 0x000055555568cc32 in Frecursive_edit () at keyboard.c:789
#17 0x00005555555a286f in main (argc=13, argv=<optimized out>) at emacs.c:2308
Which isn't very useful.
(gdb) xbacktrace
"command-line-1" (0xffffcee0)
"command-line" (0xffffd7a8)
"normal-top-level" (0xffffdc70)
And this is with all the new file locking stuff disabled. Very odd.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 21:05:01 GMT)
Full text and
rfc822 format available.
Message #137 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Hm!
I rewound back to checkout 90c89e8bdeca61aceae79e4c60a9a51800574914, and
then said
make bootstrap; touch lisp/*.el; make
and that segfaults. So this build failure doesn't seem to be related to
the locking changes. *phew* So I'm bisecting now back to the offending
commit.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 07 Jul 2021 22:23:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> I rewound back to checkout 90c89e8bdeca61aceae79e4c60a9a51800574914, and
> then said
>
> make bootstrap; touch lisp/*.el; make
>
> and that segfaults. So this build failure doesn't seem to be related to
> the locking changes. *phew* So I'm bisecting now back to the offending
> commit.
OK, I give up -- I rewound back to October 2020, and it still displays
this behaviour. I'm guessing the problem arrived on master from a
branch that was merged, but I'm not proficient enough in git to poke
through that stuff.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 08 Jul 2021 00:11:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 49261 <at> debbugs.gnu.org (full text, mbox):
To reproduce:
make bootstrap; touch lisp/*.el; make
...
make[2]: *** [Makefile:279: ../lisp/cus-start.elc] Error 139
make[1]: *** [Makefile:765: ../lisp/cus-start.elc] Error 2
/bin/sh: line 2: 113032 Segmentation fault (core dumped)
I bisected this, and git bisect pointed me to:
commit 6cf62141c4467314f67c2ef75a4bf94d41ff050f
Author: Paul Eggert <eggert <at> cs.ucla.edu>
AuthorDate: Sat Sep 5 12:13:32 2020 -0700
Reinstall recent GC-related changes
The report that they broke macOS was a false alarm, as the
previous commit was also broken (Bug#43152#62).
Running under gdb after the "make" fails:
gdb ./bootstrap-emacs
run -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -l bytecomp -f byte-compile-refresh-preloaded -f batch-byte-compile ../lisp/abbrev.elb
#0 0x00005555557103a7 in AREF (idx=23456123314108, array=0x7ffff1a398cd)
at lisp.h:731
#1 HASH_KEY (idx=11728061657054, h=0x7ffff1a39848) at lisp.h:2374
#2 hash_lookup (h=0x7ffff1a39848, key=0x555555cae444, hash=hash <at> entry=0x0)
at fns.c:4479
...
There seems to be a corruption in the hash tables somewhere. It's
totally reproducible with the recipe, but I haven't found more
self-contained example to reproduce it.
This does not show up with -O0, but does show up with -O1 and -O2.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 08 Jul 2021 06:04:01 GMT)
Full text and
rfc822 format available.
Message #146 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
Hi Lars,
> I see no regressions. Three test cases still fail
> (file-notify-test03-events-remote, shadow-test08-shadow-todo,
> shadow-test09-shadow-copy-files), but the most important one,
> tramp-test39-lock-file, still succeeds.
I've pushed another change which let all test cases succeed, as far as I
am involved. Furthermore, I have renamed auto-save--transform-file-name
to files--transform-file-name, because it isn't restricted to auto-save files.
I don't apply make bootstrap, so I'm not plagued with the segfault
problem.
> I will check tomorrow why these test cases fail, and how to integrate
> the new lock-file-name-transforms into Tramp.
This remains open for later today, or tomorrow.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 08 Jul 2021 06:15:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: michael.albinus <at> gmx.de, ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org
> Date: Thu, 08 Jul 2021 00:22:15 +0200
>
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
> > I rewound back to checkout 90c89e8bdeca61aceae79e4c60a9a51800574914, and
> > then said
> >
> > make bootstrap; touch lisp/*.el; make
> >
> > and that segfaults. So this build failure doesn't seem to be related to
> > the locking changes. *phew* So I'm bisecting now back to the offending
> > commit.
>
> OK, I give up -- I rewound back to October 2020, and it still displays
> this behaviour. I'm guessing the problem arrived on master from a
> branch that was merged, but I'm not proficient enough in git to poke
> through that stuff.
Is this only on macOS? If not, on which systems do you see this
crash?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 08 Jul 2021 06:18:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: michael.albinus <at> gmx.de, ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org
> Date: Wed, 07 Jul 2021 22:55:08 +0200
>
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
> > Still investigating... perhaps I got the lifecycle of a variable wrong
> > or something?
>
> It only happens with an -O2 build -- an -O0 build works fine. Here's
> what gdb says:
>
> #0 0x00005555557103a7 in AREF (idx=23456123314108, array=0x7ffff1a398cd)
> at lisp.h:731
> #1 HASH_KEY (idx=11728061657054, h=0x7ffff1a39848) at lisp.h:2374
> #2 hash_lookup (h=0x7ffff1a39848, key=0x555555cae444, hash=hash <at> entry=0x0)
> at fns.c:4479
> #3 0x000055555573f9f2 in exec_byte_code
> (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
> at bytecode.c:1415
> #4 0x0000555555701d07 in Ffuncall (nargs=2, args=args <at> entry=0x7fffffffcec8)
> at eval.c:3055
> #5 0x000055555573d1c8 in exec_byte_code
> (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
> at bytecode.c:632
> #6 0x0000555555701d07 in Ffuncall (nargs=1, args=args <at> entry=0x7fffffffd790)
> at eval.c:3055
> #7 0x000055555573d1c8 in exec_byte_code
> (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
> at bytecode.c:632
> #8 0x000055555570502f in apply_lambda
> (fun=0x7ffff1a23485, args=<optimized out>, count=4) at eval.c:3188
> #9 0x00005555557040b3 in eval_sub (form=<optimized out>) at eval.c:2591
> #10 0x0000555555705cd9 in Feval (form=0x7ffff1fc6b23, lexical=<optimized out>)
> at eval.c:2343
> #11 0x0000555555700da7 in internal_condition_case
> (bfun=bfun <at> entry=0x5555556872a0 <top_level_2>, handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x55555568ccf0 <cmd_error>) at eval.c:1478
> #12 0x0000555555687f26 in top_level_1 (ignore=ignore <at> entry=0x0)
> at keyboard.c:1111
> #13 0x00005555557032a3 in internal_catch
> (tag=tag <at> entry=0xe610, func=func <at> entry=0x555555687f00 <top_level_1>, arg=arg <at> entry=0x0) at eval.c:1198
> #14 0x0000555555687228 in command_loop () at lisp.h:1002
> #15 0x000055555568c906 in recursive_edit_1 () at keyboard.c:720
> #16 0x000055555568cc32 in Frecursive_edit () at keyboard.c:789
> #17 0x00005555555a286f in main (argc=13, argv=<optimized out>) at emacs.c:2308
>
>
> Which isn't very useful.
>
> (gdb) xbacktrace
> "command-line-1" (0xffffcee0)
> "command-line" (0xffffd7a8)
> "normal-top-level" (0xffffdc70)
Can you show the form being evaluated in frame #10? Like this:
(gdb) fr 10
(gdb) pp form
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 08 Jul 2021 06:21:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: michael.albinus <at> gmx.de, ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org
> Date: Wed, 07 Jul 2021 23:04:29 +0200
>
> I rewound back to checkout 90c89e8bdeca61aceae79e4c60a9a51800574914, and
> then said
>
> make bootstrap; touch lisp/*.el; make
>
> and that segfaults. So this build failure doesn't seem to be related to
> the locking changes. *phew* So I'm bisecting now back to the offending
> commit.
To make sure this is indeed segfaults for that commit, I suggest to
clone the upstream repository into a separate directory and repeat the
experiment there. There could be some left-overs of newer builds that
are not deleted/remade by a rebuild in a tree that is not 100% clean.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 08 Jul 2021 06:36:01 GMT)
Full text and
rfc822 format available.
Message #158 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 49261 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> Date: Thu, 08 Jul 2021 02:09:45 +0200
>
> To reproduce:
>
> make bootstrap; touch lisp/*.el; make
>
> ...
> make[2]: *** [Makefile:279: ../lisp/cus-start.elc] Error 139
> make[1]: *** [Makefile:765: ../lisp/cus-start.elc] Error 2
> /bin/sh: line 2: 113032 Segmentation fault (core dumped)
>
>
> I bisected this, and git bisect pointed me to:
>
> commit 6cf62141c4467314f67c2ef75a4bf94d41ff050f
> Author: Paul Eggert <eggert <at> cs.ucla.edu>
> AuthorDate: Sat Sep 5 12:13:32 2020 -0700
>
> Reinstall recent GC-related changes
>
> The report that they broke macOS was a false alarm, as the
> previous commit was also broken (Bug#43152#62).
So the last paragraph above is incorrect, and "the previous commit" is
not broken? Then what about the information in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43152#65
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43152#68
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43152#71
And the rest of the discussion about verify.h being the culprit?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 08 Jul 2021 12:44:01 GMT)
Full text and
rfc822 format available.
Message #161 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Can you show the form being evaluated in frame #10? Like this:
>
> (gdb) fr 10
> (gdb) pp form
Hm:
(gdb) fr 10
#10 0x0000555555706a59 in Feval (form=XIL(0x7ffff20f5023),
lexical=<optimized out>) at eval.c:2343
2343 return unbind_to (count, eval_sub (form));
(gdb) pp form
#<INVALID_LISP_OBJECT 0x7ffff20f5023>
This is with an -O2 build; the bug also reproduces with an -O1 build;
I'll try that...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 08 Jul 2021 12:45:02 GMT)
Full text and
rfc822 format available.
Message #164 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> To make sure this is indeed segfaults for that commit, I suggest to
> clone the upstream repository into a separate directory and repeat the
> experiment there. There could be some left-overs of newer builds that
> are not deleted/remade by a rebuild in a tree that is not 100% clean.
I'm doing a "git clean -xf" between each build, which should remove
everything that's not from upstream, I think?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 08 Jul 2021 12:50:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> This is with an -O2 build; the bug also reproduces with an -O1 build;
> I'll try that...
Here's the -O1 backtrace:
Thread 1 "bootstrap-emacs" received signal SIGSEGV, Segmentation fault.
0x00005555556f0549 in AREF (idx=6988131860, array=XIL(0x7ffff1bd901d))
at lisp.h:731
731 return lisp_h_XLP (o);
(gdb) bt
#0 0x00005555556f0549 in AREF (idx=6988131860, array=XIL(0x7ffff1bd901d))
at lisp.h:731
#1 HASH_KEY (idx=3494065930, h=0x7ffff1bd8f98) at lisp.h:2374
#2 hash_lookup
(h=0x7ffff1bd8f98, key=XIL(0x555555c76c64), hash=hash <at> entry=0x0)
at fns.c:4479
#3 0x0000555555719cb9 in exec_byte_code
(bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=args_template <at> entry=make_fixnum(257), nargs=nargs <at> entry=1, args=<optimized out>, args <at> entry=0x7fffffffd940) at bytecode.c:1415
#4 0x00005555556e643f in fetch_and_exec_byte_code
(args=0x7fffffffd940, nargs=1, syms_left=make_fixnum(257), fun=XIL(0x7ffff1bc9895)) at lisp.h:731
#5 funcall_lambda
(fun=XIL(0x7ffff1bc9895), nargs=nargs <at> entry=1, arg_vector=arg_vector <at> entry=0x7fffffffd940) at eval.c:3244
#6 0x00005555556e3bb4 in Ffuncall (nargs=2, args=args <at> entry=0x7fffffffd938)
at eval.c:3043
#7 0x0000555555717cb6 in exec_byte_code
(bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=args_template <at> entry=make_fixnum(0), nargs=nargs <at> entry=0, args=<optimized out>, args <at> entry=0x7fffffffe0e8) at bytecode.c:632
#8 0x00005555556e643f in fetch_and_exec_byte_code
(args=0x7fffffffe0e8, nargs=0, syms_left=make_fixnum(0), fun=XIL(0x7ffff1bc79ed)) at lisp.h:731
#9 funcall_lambda
(fun=XIL(0x7ffff1bc79ed), nargs=nargs <at> entry=0, arg_vector=arg_vector <at> entry=0x7fffffffe0e8) at eval.c:3244
#10 0x00005555556e3bb4 in Ffuncall (nargs=1, args=args <at> entry=0x7fffffffe0e0)
at eval.c:3043
#11 0x0000555555717cb6 in exec_byte_code
(bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=args_template <at> entry=make_fixnum(0), nargs=nargs <at> entry=0, args=<optimized out>, args <at> entry=0x7fffffffe4a0) at bytecode.c:632
#12 0x00005555556e643f in fetch_and_exec_byte_code
(args=0x7fffffffe4a0, nargs=0, syms_left=make_fixnum(0), fun=XIL(0x7ffff1bc759d)) at lisp.h:731
#13 funcall_lambda
(fun=fun <at> entry=XIL(0x7ffff1bc759d), nargs=nargs <at> entry=0, arg_vector=arg_vector <at> entry=0x7fffffffe4a0) at eval.c:3244
#14 0x00005555556e5aec in apply_lambda
(fun=fun <at> entry=XIL(0x7ffff1bc759d), args=<optimized out>, count=count <at> entry=4) at eval.c:3188
#15 0x00005555556e5d64 in eval_sub (form=form <at> entry=XIL(0x7ffff20f4fe3))
at eval.c:2561
#16 0x00005555556e76d7 in Feval
--Type <RET> for more, q to quit, c to continue without paging--
(form=XIL(0x7ffff20f4fe3), lexical=lexical <at> entry=XIL(0)) at eval.c:2343
#17 0x0000555555670a48 in top_level_2 () at lisp.h:1002
#18 0x00005555556e2f8d in internal_condition_case
(bfun=bfun <at> entry=0x555555670a33 <top_level_2>, handlers=handlers <at> entry=XIL(0x90), hfun=hfun <at> entry=0x555555673df4 <cmd_error>) at eval.c:1478
#19 0x0000555555670a03 in top_level_1 (ignore=ignore <at> entry=XIL(0))
at keyboard.c:1111
#20 0x00005555556e5158 in internal_catch
(tag=tag <at> entry=XIL(0xe610), func=func <at> entry=0x5555556709dd <top_level_1>, arg=arg <at> entry=XIL(0)) at eval.c:1198
#21 0x0000555555670986 in command_loop () at lisp.h:1002
#22 0x0000555555673a9c in recursive_edit_1 () at keyboard.c:720
#23 0x0000555555673d4d in Frecursive_edit () at keyboard.c:789
#24 0x000055555566fea2 in main (argc=13, argv=0x7fffffffe8b8) at emacs.c:2308
Lisp Backtrace:
"command-line-1" (0xffffd940)
"command-line" (0xffffe0e8)
"normal-top-level" (0xffffe4a0)
(gdb) fr 16
#16 0x00005555556e76d7 in Feval (form=XIL(0x7ffff20f4fe3),
lexical=lexical <at> entry=XIL(0)) at eval.c:2343
2343 return unbind_to (count, eval_sub (form));
(gdb) pp form
#<INVALID_LISP_OBJECT 0x7ffff20f4fe3>
(gdb)
Same invalid object.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 08 Jul 2021 12:52:02 GMT)
Full text and
rfc822 format available.
Message #170 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> So the last paragraph above is incorrect, and "the previous commit" is
> not broken? Then what about the information in
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43152#65
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43152#68
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43152#71
>
> And the rest of the discussion about verify.h being the culprit?
Hm... is that for Macos only, though? I'm currently doing the testing
on Linux (Debian and Fedora, which both displays the same behaviour).
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 08 Jul 2021 13:12:01 GMT)
Full text and
rfc822 format available.
Message #173 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> I'm doing a "git clean -xf" between each build, which should remove
> everything that's not from upstream, I think?
Just to ensure that there's nothing there, I did:
git clone git://git.savannah.gnu.org/emacs.git
cd emacs
git checkout 6cf62141c4467314f67c2ef75a4bf94d41ff050f
sh autogen.sh; ./configure; make -j16; touch lisp/*.el; make
This segfaults for me reliably on Debian and Fedora.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 08 Jul 2021 13:14:02 GMT)
Full text and
rfc822 format available.
Message #176 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: michael.albinus <at> gmx.de, ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org
> Date: Thu, 08 Jul 2021 14:44:31 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > To make sure this is indeed segfaults for that commit, I suggest to
> > clone the upstream repository into a separate directory and repeat the
> > experiment there. There could be some left-overs of newer builds that
> > are not deleted/remade by a rebuild in a tree that is not 100% clean.
>
> I'm doing a "git clean -xf" between each build, which should remove
> everything that's not from upstream, I think?
Theoretically, yes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 08 Jul 2021 13:18:02 GMT)
Full text and
rfc822 format available.
Message #179 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: michael.albinus <at> gmx.de, ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org
> Date: Thu, 08 Jul 2021 14:42:44 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Can you show the form being evaluated in frame #10? Like this:
> >
> > (gdb) fr 10
> > (gdb) pp form
>
> Hm:
>
> (gdb) fr 10
> #10 0x0000555555706a59 in Feval (form=XIL(0x7ffff20f5023),
> lexical=<optimized out>) at eval.c:2343
> 2343 return unbind_to (count, eval_sub (form));
> (gdb) pp form
> #<INVALID_LISP_OBJECT 0x7ffff20f5023>
Which means unfortunately that to see the form one needs to display
the form piecemeal, one member at a time, using the xtype and the
other x* commands... Let me know if you need more detailed
instructions.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 08 Jul 2021 13:36:02 GMT)
Full text and
rfc822 format available.
Message #182 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Which means unfortunately that to see the form one needs to display
> the form piecemeal, one member at a time, using the xtype and the
> other x* commands... Let me know if you need more detailed
> instructions.
Yes, that'd be appreciated.
(gdb) print form
$1 = XIL(0x7ffff211c263)
(gdb) pr form
#<INVALID_LISP_OBJECT 0x7ffff211c263>
(gdb) xtype form
Lisp_Cons
(gdb) xcons form
$2 = (struct Lisp_Cons *) 0x7ffff211c260
{
u = {
s = {
car = XIL(0x2aaa9c41a9e0),
u = {
cdr = XIL(0),
chain = 0x0
}
},
gcaligned = 0xe0
}
}
(gdb) xcar form
$3 = 0x0
(gdb) xcdr form
$4 = 0x0
Which doesn't seem ... right?
Anyway, the build failures (on the old commit) aren't 100% reproducible
now. When running the bootstrap under gdb, it now currently just hangs,
so I have to C-c to get the backtrace. It does hang (always) at the
same place (see below).
So I'm still guessing that there's memory corruption introduced by the
patch, so actually looking at the backtrace may not be very
productive...
Reloading stale subdirs.el
Loading /tmp/emacs/lisp/subdirs.el (source)...
^C
Thread 1 "bootstrap-emacs" hit Breakpoint 1, terminate_due_to_signal (
sig=sig <at> entry=2, backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:378
378 signal (sig, SIG_DFL);
(gdb) bt
#0 terminate_due_to_signal
(sig=sig <at> entry=2, backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:378
#1 0x0000555555599698 in handle_fatal_signal (sig=sig <at> entry=2)
at sysdep.c:1768
#2 0x00005555555996ae in deliver_process_signal
(handler=0x55555559968d <handle_fatal_signal>, sig=2) at sysdep.c:1726
#3 deliver_fatal_signal (sig=2) at sysdep.c:1774
#4 0x00007ffff59e3140 in <signal handler called> ()
at /lib/x86_64-linux-gnu/libpthread.so.0
#5 hash_lookup
(h=0x7ffff1fbe518, key=XIL(0x555555c54b94), hash=hash <at> entry=0x0)
at lisp.h:718
#6 0x00005555557392a2 in exec_byte_code
(bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
at bytecode.c:1415
#7 0x00005555556fdeb7 in Ffuncall (nargs=2, args=args <at> entry=0x7fffffffd6b8)
at eval.c:2809
#8 0x0000555555736a78 in exec_byte_code
(bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
at bytecode.c:632
#9 0x00005555556fdeb7 in Ffuncall (nargs=1, args=args <at> entry=0x7fffffffe040)
--Type <RET> for more, q to quit, c to continue without paging--
at eval.c:2809
#10 0x0000555555736a78 in exec_byte_code
(bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
at bytecode.c:632
#11 0x0000555555700e7f in apply_lambda
(fun=XIL(0x7ffff1fc26f5), args=<optimized out>, count=4) at eval.c:2942
#12 0x00005555556fff03 in eval_sub (form=<optimized out>) at eval.c:2349
#13 0x0000555555701a29 in Feval
(form=XIL(0x7ffff211c263), lexical=<optimized out>) at eval.c:2103
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 08 Jul 2021 16:48:01 GMT)
Full text and
rfc822 format available.
Message #185 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: michael.albinus <at> gmx.de, ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org
> Date: Thu, 08 Jul 2021 15:34:54 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Which means unfortunately that to see the form one needs to display
> > the form piecemeal, one member at a time, using the xtype and the
> > other x* commands... Let me know if you need more detailed
> > instructions.
>
> Yes, that'd be appreciated.
Well, you did it (almost) correctly:
> (gdb) xtype form
> Lisp_Cons
> (gdb) xcons form
> $2 = (struct Lisp_Cons *) 0x7ffff211c260
> {
> u = {
> s = {
> car = XIL(0x2aaa9c41a9e0),
> u = {
> cdr = XIL(0),
> chain = 0x0
> }
> },
> gcaligned = 0xe0
> }
> }
> (gdb) xcar form
> $3 = 0x0
> (gdb) xcdr form
> $4 = 0x0
What you need to do is this:
(gdb) xtype
Lisp_Cons
(gdb) xcons
$2 = (struct Lisp_Cons *) 0x7ffff211c260
{
u = {
s = {
car = XIL(0x2aaa9c41a9e0),
u = {
cdr = XIL(0),
chain = 0x0
}
},
gcaligned = 0xe0
}
}
(gdb) p $2->u.s.car
(gdb) xtype
And after the second "xtype" continue with the x* command according to
the type.
Your mistake was to use an argument after xcons, xcar, and xcdr: these
should be invoked without an argument, immediately after printing a
Lisp_Object variable. Like this:
(gdb) p form
(gdb) xcar
(gdb) p form
(gdb) xcdr
etc.
> Which doesn't seem ... right?
No, but the real form has a non-nil 'car', see above. So that does
look valid, at least at this level. The invalid part probably comes
when you recurse deeper into 'form'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 08 Jul 2021 19:54:01 GMT)
Full text and
rfc822 format available.
Message #188 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
Hi Lars,
>> I will check tomorrow why these test cases fail, and how to integrate
>> the new lock-file-name-transforms into Tramp.
>
> This remains open for later today, or tomorrow.
This is done. ATM, I've decided not to write an own Tramp handler for
make-lock-file-name, the default function is good enough. But the
infrastructure for such a handler is prepared, when needed.
One point I am missing is to suppress lock files, customised by
users. There is create-lockfiles, but this is all-or-nothing. One idea
we've discussed shortly would be to add a file-lock-mode, similar to the
existing auto-save-mode. Would be useful, but it is restricted to the
current buffer.
Another idea I have is to use the new lock-file-name-transforms user
option. It contains entries (REGEXP REPLACEMENT UNIQUIFY) .
What if we allow REPLACEMENT to be nil, meaning that there shoudn't be
file locks for files matching REGEXP? An entry
("\\`/[^/]*:\\([^/]*/\\)*\\([^/]*\\)\\'") of that variable would
suppress file locks for remote files then.
A similar meaning could be offered for auto-save-file-name-transforms.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Fri, 09 Jul 2021 06:31:02 GMT)
Full text and
rfc822 format available.
Message #191 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, ncaprisunfan <at> gmail.com,
> 49261 <at> debbugs.gnu.org
> Date: Thu, 08 Jul 2021 21:53:08 +0200
>
> One point I am missing is to suppress lock files, customised by
> users. There is create-lockfiles, but this is all-or-nothing.
What other degrees besides "all" and "nothing" would you like to have?
And why?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Fri, 09 Jul 2021 08:29:02 GMT)
Full text and
rfc822 format available.
Message #194 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> One point I am missing is to suppress lock files, customised by
>> users. There is create-lockfiles, but this is all-or-nothing.
>
> What other degrees besides "all" and "nothing" would you like to have?
> And why?
Remote files (all files which match tramp-file-name-regexp). For
backward compatibility, and possibly due to performance reasons.
Mounted files (all files which match `mounted-file-systems'). Possibly
due to performance reasons.
These are just examples. One could imagine more fine-grained choices
(for example, only files located on a given host), or completely other
selections.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Fri, 09 Jul 2021 10:46:01 GMT)
Full text and
rfc822 format available.
Message #197 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: larsi <at> gnus.org, ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org
> Date: Fri, 09 Jul 2021 10:28:29 +0200
>
> > What other degrees besides "all" and "nothing" would you like to have?
> > And why?
>
> Remote files (all files which match tramp-file-name-regexp). For
> backward compatibility, and possibly due to performance reasons.
>
> Mounted files (all files which match `mounted-file-systems'). Possibly
> due to performance reasons.
You want a capability to exempt different kinds of files from locking?
Why would that be a good idea? Performance doesn't cut it, IMO,
because if one wants to be protected from clobbering, one doesn't care
about performance. And if one cares about performance for those
special kinds of files, it most probably means one doesn't care about
file locking at all.
So I submit that a binary switch is good enough.
> These are just examples. One could imagine more fine-grained choices
> (for example, only files located on a given host), or completely other
> selections.
I suggest not to imagine potential features. We already have too many
features, so we should only add new ones if they are really required.
just because someone could use a finer-grained setting doesn't yet
mean we need to cater to that in core.
In any case, now that make-lock-file-name is exposed to Lisp, they can
override or advise it to do whatever they like, right?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Fri, 09 Jul 2021 11:02:01 GMT)
Full text and
rfc822 format available.
Message #200 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> Remote files (all files which match tramp-file-name-regexp). For
>> backward compatibility, and possibly due to performance reasons.
>
> You want a capability to exempt different kinds of files from locking?
> Why would that be a good idea? Performance doesn't cut it, IMO,
> because if one wants to be protected from clobbering, one doesn't care
> about performance. And if one cares about performance for those
> special kinds of files, it most probably means one doesn't care about
> file locking at all.
>
> So I submit that a binary switch is good enough.
Until now, there are no file locks for remote files at all. I thought disabling
it for remote files would be requested by some users for backward compatibility.
> In any case, now that make-lock-file-name is exposed to Lisp, they can
> override or advise it to do whatever they like, right?
Yes. But they cannot disable it. Advising the function is always
possible, but it is less convenient than a user option setting.
But well, let's see whether people shout ...
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Fri, 09 Jul 2021 16:32:02 GMT)
Full text and
rfc822 format available.
Message #203 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> Until now, there are no file locks for remote files at all. I thought
> disabling it for remote files would be requested by some users for
> backward compatibility.
Yeah, I think it's a good idea, and allowing REPLACEMENT to be nil seems
like the natural way to implement it.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Sat, 10 Jul 2021 16:26:01 GMT)
Full text and
rfc822 format available.
Message #206 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> (gdb) p $2->u.s.car
> (gdb) xtype
>
> And after the second "xtype" continue with the x* command according to
> the type.
Ah, thanks:
gdb) xtype
Lisp_Cons
(gdb) xcons
$2 = (struct Lisp_Cons *) 0x7ffff211c260
{
u = {
s = {
car = XIL(0x2aaa9c41a9e0),
u = {
cdr = XIL(0),
chain = 0x0
}
},
gcaligned = 0xe0
}
}
(gdb) p $2->u.s.car
$3 = XIL(0x2aaa9c41a9e0)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$4 = (struct Lisp_Symbol *) 0x7ffff1fc26c0
"normal-top-level"
(gdb)
So it's segfaulting while evaling normal-top-level?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Sat, 10 Jul 2021 17:06:01 GMT)
Full text and
rfc822 format available.
Message #209 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: michael.albinus <at> gmx.de, ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org
> Date: Sat, 10 Jul 2021 18:25:27 +0200
>
> (gdb) p $2->u.s.car
> $3 = XIL(0x2aaa9c41a9e0)
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $4 = (struct Lisp_Symbol *) 0x7ffff1fc26c0
> "normal-top-level"
> (gdb)
>
> So it's segfaulting while evaling normal-top-level?
Yes. Which is consistent with the backtrace, so this didn't teach us
anything new.
It would be good to try to understand byte code of which function is
being run in frame #3 here:
> Thread 1 "bootstrap-emacs" received signal SIGSEGV, Segmentation fault.
> 0x00005555556f0549 in AREF (idx=6988131860, array=XIL(0x7ffff1bd901d))
> at lisp.h:731
> 731 return lisp_h_XLP (o);
> (gdb) bt
> #0 0x00005555556f0549 in AREF (idx=6988131860, array=XIL(0x7ffff1bd901d))
> at lisp.h:731
> #1 HASH_KEY (idx=3494065930, h=0x7ffff1bd8f98) at lisp.h:2374
> #2 hash_lookup
> (h=0x7ffff1bd8f98, key=XIL(0x555555c76c64), hash=hash <at> entry=0x0)
> at fns.c:4479
> #3 0x0000555555719cb9 in exec_byte_code
> (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=args_template <at> entry=make_fixnum(257), nargs=nargs <at> entry=1, args=<optimized out>, args <at> entry=0x7fffffffd940) at bytecode.c:1415
> #4 0x00005555556e643f in fetch_and_exec_byte_code
> (args=0x7fffffffd940, nargs=1, syms_left=make_fixnum(257), fun=XIL(0x7ffff1bc9895)) at lisp.h:731
> #5 funcall_lambda
> (fun=XIL(0x7ffff1bc9895), nargs=nargs <at> entry=1, arg_vector=arg_vector <at> entry=0x7fffffffd940) at eval.c:3244
The problem is this is an optimized build and many variables are
"optimized out".
Line 1415 of bytecomp.c is here:
CASE (Bswitch):
{
/* TODO: Perhaps introduce another byte-code for switch when the
number of cases is less, which uses a simple vector for linear
search as the jump table. */
Lisp_Object jmp_table = POP;
if (BYTE_CODE_SAFE && !HASH_TABLE_P (jmp_table))
emacs_abort ();
Lisp_Object v1 = POP;
ptrdiff_t i;
struct Lisp_Hash_Table *h = XHASH_TABLE (jmp_table);
/* h->count is a faster approximation for HASH_TABLE_SIZE (h)
here. */
if (h->count <= 5 && !h->test.cmpfn)
{ /* Do a linear search if there are not many cases
FIXME: 5 is arbitrarily chosen. */
for (i = h->count; 0 <= --i; )
if (EQ (v1, HASH_KEY (h, i)))
break;
}
else
i = hash_lookup (h, v1, NULL); <<<<<<<<<<<<<<<<<
Stefan, what code in command-line-1 is likely to produce the Bswitch
byte-code?
Anyway, looking at frame 1, I guess the value of 'idx' is bogus, which
means something is wrong with the hash table. So maybe we should
audit the part(s) of the offending commit that have something to do
with hash tables? Also, what kind of hash-table are we looking up
there, is it possible to understand that by looking at the variables
involved in the above code?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Sat, 10 Jul 2021 17:17:02 GMT)
Full text and
rfc822 format available.
Message #212 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> It would be good to try to understand byte code of which function is
> being run in frame #3 here:
>
>> Thread 1 "bootstrap-emacs" received signal SIGSEGV, Segmentation fault.
>> 0x00005555556f0549 in AREF (idx=6988131860, array=XIL(0x7ffff1bd901d))
>> at lisp.h:731
>> 731 return lisp_h_XLP (o);
>> (gdb) bt
>> #0 0x00005555556f0549 in AREF (idx=6988131860, array=XIL(0x7ffff1bd901d))
>> at lisp.h:731
>> #1 HASH_KEY (idx=3494065930, h=0x7ffff1bd8f98) at lisp.h:2374
>> #2 hash_lookup
>> (h=0x7ffff1bd8f98, key=XIL(0x555555c76c64), hash=hash <at> entry=0x0)
>> at fns.c:4479
Well, the segfault is in this:
for (i = HASH_INDEX (h, start_of_bucket); 0 <= i; i = HASH_NEXT (h, i))
{
and you can see that idx (i.e., i here) is 3494065930, which is a very
unusual value for idx -- it's usually below 2K. So it can't really be
anything other than a memory corruption issue, I think?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Sat, 10 Jul 2021 17:21:02 GMT)
Full text and
rfc822 format available.
Message #215 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, michael.albinus <at> gmx.de,
> ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org, Paul Eggert
> <eggert <at> cs.ucla.edu>
> Date: Sat, 10 Jul 2021 19:15:53 +0200
>
> >> 731 return lisp_h_XLP (o);
> >> (gdb) bt
> >> #0 0x00005555556f0549 in AREF (idx=6988131860, array=XIL(0x7ffff1bd901d))
> >> at lisp.h:731
> >> #1 HASH_KEY (idx=3494065930, h=0x7ffff1bd8f98) at lisp.h:2374
> >> #2 hash_lookup
> >> (h=0x7ffff1bd8f98, key=XIL(0x555555c76c64), hash=hash <at> entry=0x0)
> >> at fns.c:4479
>
> Well, the segfault is in this:
>
> for (i = HASH_INDEX (h, start_of_bucket); 0 <= i; i = HASH_NEXT (h, i))
> {
>
> and you can see that idx (i.e., i here) is 3494065930, which is a very
> unusual value for idx -- it's usually below 2K. So it can't really be
> anything other than a memory corruption issue, I think?
Yes, but why? and in which hash-table?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Sun, 11 Jul 2021 08:37:01 GMT)
Full text and
rfc822 format available.
Message #218 received at 49261 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 7/7/21 5:09 PM, Lars Ingebrigtsen wrote:
> There seems to be a corruption in the hash tables somewhere. It's
> totally reproducible with the recipe
Thanks for the recipe; it let me reproduce the problem on Fedora 34 x86-64.
The problem comes from the fact that mark_maybe_pointer works
differently on pdumper objects than it works on ordinary objects. On
ordinary objects, roots can point anywhere into an object (because this
sort of thing has happened on real machines), whereas on pdumper
objects, roots had to point to the start of the object.
I worked around this particular problem changing mark_maybe_pointer so
that pdumper roots can also be tagged (see first attached patch).
However, I suspect this is not a complete fix, as it doesn't cover the
case where a root points to some part of a pdumper object that is not at
the object's start. I added a FIXME about this. Perhaps Daniel can take
a look at it sometime. I think the remaining bug will be hit only rarely
(if ever).
The second attached patch is in the same area, but is not part of the
fix. It causes the GC to be a bit more accurate (i.e., less
conservative) for roots, which can help avoid some leaks.
[0001-Fix-pdumper-related-GC-bug.patch (text/x-patch, attachment)]
[0002-Make-pdumper-marking-pickier.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Sun, 11 Jul 2021 10:22:02 GMT)
Full text and
rfc822 format available.
Message #221 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> Cc: 49261 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 11 Jul 2021 01:36:21 -0700
>
> I worked around this particular problem changing mark_maybe_pointer so
> that pdumper roots can also be tagged (see first attached patch).
> However, I suspect this is not a complete fix, as it doesn't cover the
> case where a root points to some part of a pdumper object that is not at
> the object's start. I added a FIXME about this. Perhaps Daniel can take
> a look at it sometime. I think the remaining bug will be hit only rarely
> (if ever).
>
> The second attached patch is in the same area, but is not part of the
> fix. It causes the GC to be a bit more accurate (i.e., less
> conservative) for roots, which can help avoid some leaks.
Thanks, but these changes don't cater to 32-bit builds --with-wide-int:
CC alloc.o
In file included from alloc.c:33:
alloc.c: In function 'mark_maybe_pointer':
lisp.h:251:18: warning: unsigned conversion from 'long long int' to 'uintptr_t' {aka 'unsigned int'} changes value from '2305843009213693951' to '4294967295' [-Woverflow]
251 | # define VALMASK (USE_LSB_TAG ? - (1 << GCTYPEBITS) : VAL_MAX)
| ^
alloc.c:4767:24: note: in expansion of macro 'VALMASK'
4767 | uintptr_t mask = VALMASK;
| ^~~~~~~
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Sun, 11 Jul 2021 11:34:02 GMT)
Full text and
rfc822 format available.
Message #224 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> I worked around this particular problem changing mark_maybe_pointer so
> that pdumper roots can also be tagged (see first attached
> patch).
Thanks; I can confirm that I can no longer reproduce the crash after
this patch.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Sun, 11 Jul 2021 15:26:02 GMT)
Full text and
rfc822 format available.
Message #227 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 11 Jul 2021 13:21:16 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: larsi <at> gnus.org, 49261 <at> debbugs.gnu.org
>
> Thanks, but these changes don't cater to 32-bit builds --with-wide-int:
>
> CC alloc.o
> In file included from alloc.c:33:
> alloc.c: In function 'mark_maybe_pointer':
> lisp.h:251:18: warning: unsigned conversion from 'long long int' to 'uintptr_t' {aka 'unsigned int'} changes value from '2305843009213693951' to '4294967295' [-Woverflow]
> 251 | # define VALMASK (USE_LSB_TAG ? - (1 << GCTYPEBITS) : VAL_MAX)
> | ^
> alloc.c:4767:24: note: in expansion of macro 'VALMASK'
> 4767 | uintptr_t mask = VALMASK;
> | ^~~~~~~
I tried to fix this on master, please take a look.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Mon, 12 Jul 2021 07:17:02 GMT)
Full text and
rfc822 format available.
Message #230 received at 49261 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 7/11/21 8:25 AM, Eli Zaretskii wrote:
>> lisp.h:251:18: warning: unsigned conversion from 'long long int' to 'uintptr_t' {aka 'unsigned int'} changes value from '2305843009213693951' to '4294967295' [-Woverflow]
>> 251 | # define VALMASK (USE_LSB_TAG ? - (1 << GCTYPEBITS) : VAL_MAX)
>> | ^
>> alloc.c:4767:24: note: in expansion of macro 'VALMASK'
>> 4767 | uintptr_t mask = VALMASK;
>> | ^~~~~~~
> I tried to fix this on master, please take a look.
Yes that GCC warning was bogus, and your pacification of GCC is valid
now that we no longer tag the MSB of pointers. Still, there should be a
simpler way to pacify GCC so I installed a further fix that I hope does
that (see first attached patch). This fix simply uses a cast (uintptr_t)
VALMASK to pacify GCC; if GCC issues a bogus warning even for that cast,
we could substitute (uintptr_t) (VALMASK & UINTPTR_MAX) though this is
starting to get a little ridiculous.
The version of GCC that I tried (11.1.1 20210531 (Red Hat 11.1.1-3))
don't warn about the original code, so perhaps the bogus warning that
you saw is a GCC bug that's been fixed in later GCC versions. However,
GCC 11.1.1 does warn about some other stuff so I installed the remaining
patches to pacify it. Some of these patches fix real (albeit unlikely)
bugs in Emacs. Some work around what are evidently flaws in GCC 11.1.1.
Oh well.
[0001-Pacify-gcc-Woverflow-more-nicely.patch (text/x-patch, attachment)]
[0002-Pacify-gcc-11.1.1-Wanalyzer-null-argument.patch (text/x-patch, attachment)]
[0003-Pacify-gcc-11.1.1-Wanalyzer-possible-null-dereferenc.patch (text/x-patch, attachment)]
[0004-Pacify-gcc-11.1.1-Wclobbered.patch (text/x-patch, attachment)]
[0005-Port-test-module-to-glibc-2.33.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Mon, 12 Jul 2021 12:08:01 GMT)
Full text and
rfc822 format available.
Message #233 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> Cc: larsi <at> gnus.org, 49261 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Mon, 12 Jul 2021 00:16:07 -0700
>
> >> lisp.h:251:18: warning: unsigned conversion from 'long long int' to 'uintptr_t' {aka 'unsigned int'} changes value from '2305843009213693951' to '4294967295' [-Woverflow]
> >> 251 | # define VALMASK (USE_LSB_TAG ? - (1 << GCTYPEBITS) : VAL_MAX)
> >> | ^
> >> alloc.c:4767:24: note: in expansion of macro 'VALMASK'
> >> 4767 | uintptr_t mask = VALMASK;
> >> | ^~~~~~~
> > I tried to fix this on master, please take a look.
>
> Yes that GCC warning was bogus, and your pacification of GCC is valid
Hmm... is it really a bogus warning? VALMASK is a 64-bit value, and
uintptr_t is 32-bit wide.
> now that we no longer tag the MSB of pointers. Still, there should be a
> simpler way to pacify GCC so I installed a further fix that I hope does
> that (see first attached patch). This fix simply uses a cast (uintptr_t)
> VALMASK to pacify GCC; if GCC issues a bogus warning even for that cast,
> we could substitute (uintptr_t) (VALMASK & UINTPTR_MAX) though this is
> starting to get a little ridiculous.
Your fix compiles cleanly, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Mon, 12 Jul 2021 13:54:02 GMT)
Full text and
rfc822 format available.
Message #236 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>> Until now, there are no file locks for remote files at all. I thought
>> disabling it for remote files would be requested by some users for
>> backward compatibility.
>
> Yeah, I think it's a good idea, and allowing REPLACEMENT to be nil seems
> like the natural way to implement it.
And now? You and Eli disagree in this point, and I don't know what to do.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Mon, 12 Jul 2021 14:04:01 GMT)
Full text and
rfc822 format available.
Message #239 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, ncaprisunfan <at> gmail.com,
> 49261 <at> debbugs.gnu.org
> Date: Mon, 12 Jul 2021 15:53:12 +0200
>
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
> >> Until now, there are no file locks for remote files at all. I thought
> >> disabling it for remote files would be requested by some users for
> >> backward compatibility.
> >
> > Yeah, I think it's a good idea, and allowing REPLACEMENT to be nil seems
> > like the natural way to implement it.
>
> And now? You and Eli disagree in this point, and I don't know what to do.
Which disagreement between us leaves you at an impasse? If there is
indeed such a disagreement, maybe we could find a compromise which
will allow some way forward.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Mon, 12 Jul 2021 14:38:01 GMT)
Full text and
rfc822 format available.
Message #242 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>>
>> >> Until now, there are no file locks for remote files at all. I thought
>> >> disabling it for remote files would be requested by some users for
>> >> backward compatibility.
>> >
>> > Yeah, I think it's a good idea, and allowing REPLACEMENT to be nil seems
>> > like the natural way to implement it.
>>
>> And now? You and Eli disagree in this point, and I don't know what to do.
>
> Which disagreement between us leaves you at an impasse? If there is
> indeed such a disagreement, maybe we could find a compromise which
> will allow some way forward.
Lars agrees my proposal to use lock-file-name-transforms for disabling
file locks. You did argue against.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Mon, 12 Jul 2021 14:51:01 GMT)
Full text and
rfc822 format available.
Message #245 received at 49261 <at> debbugs.gnu.org (full text, mbox):
On 7/12/21 5:07 AM, Eli Zaretskii wrote:
>> Yes that GCC warning was bogus, and your pacification of GCC is valid
>
> Hmm... is it really a bogus warning? VALMASK is a 64-bit value, and
> uintptr_t is 32-bit wide.
It's bogus in the sense that 'uintptr_t mask = VALMASK;' has
well-defined behavior in C; there is no undefined behavior there, since
VALMASK is an integer and uintptr_t is unsigned. And truncation is what
is wanted here, so the warning is bogus.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Mon, 12 Jul 2021 14:57:02 GMT)
Full text and
rfc822 format available.
Message #248 received at 49261 <at> debbugs.gnu.org (full text, mbox):
The warning isn't bogus. It points out a potential bug. That's what
warnings are all about.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Mon, 12 Jul 2021 15:55:02 GMT)
Full text and
rfc822 format available.
Message #251 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> Cc: larsi <at> gnus.org, 49261 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Mon, 12 Jul 2021 07:50:41 -0700
>
> On 7/12/21 5:07 AM, Eli Zaretskii wrote:
>
> >> Yes that GCC warning was bogus, and your pacification of GCC is valid
> >
> > Hmm... is it really a bogus warning? VALMASK is a 64-bit value, and
> > uintptr_t is 32-bit wide.
>
> It's bogus in the sense that 'uintptr_t mask = VALMASK;' has
> well-defined behavior in C; there is no undefined behavior there, since
> VALMASK is an integer and uintptr_t is unsigned. And truncation is what
> is wanted here, so the warning is bogus.
Then what is the -Woverflow option for? Can you show an example of
code which -Woverflow would flag that doesn't produce a bogus warning?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Mon, 12 Jul 2021 17:31:01 GMT)
Full text and
rfc822 format available.
Message #254 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: larsi <at> gnus.org, ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org
> Date: Mon, 12 Jul 2021 16:37:45 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Hi Eli,
>
> >> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> >>
> >> >> Until now, there are no file locks for remote files at all. I thought
> >> >> disabling it for remote files would be requested by some users for
> >> >> backward compatibility.
> >> >
> >> > Yeah, I think it's a good idea, and allowing REPLACEMENT to be nil seems
> >> > like the natural way to implement it.
> >>
> >> And now? You and Eli disagree in this point, and I don't know what to do.
> >
> > Which disagreement between us leaves you at an impasse? If there is
> > indeed such a disagreement, maybe we could find a compromise which
> > will allow some way forward.
>
> Lars agrees my proposal to use lock-file-name-transforms for disabling
> file locks. You did argue against.
Are we talking about disabling remote locks by default? If so, how
about disabling them via a more user-friendly option? It strikes me
as weird and un-intuitive to _disable_ something via a "transform"
function. And it will definitely be more complex to set up such a
"transform" function than just use a boolean flag.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Mon, 12 Jul 2021 17:36:01 GMT)
Full text and
rfc822 format available.
Message #257 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Are we talking about disabling remote locks by default? If so, how
> about disabling them via a more user-friendly option? It strikes me
> as weird and un-intuitive to _disable_ something via a "transform"
> function. And it will definitely be more complex to set up such a
> "transform" function than just use a boolean flag.
The thing is: In Emacs 27, we didn't have file locking for Tramp files.
This has now been introduced, and we're discussing how to disable them
(and only them) in Emacs 28.
Doing that as a transform seems natural, since that's very parallel to
what we're doing in `auto-save-file-name-transforms' (where Tramp file
names are made local).
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Mon, 12 Jul 2021 17:39:02 GMT)
Full text and
rfc822 format available.
Message #260 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Michael Albinus <michael.albinus <at> gmx.de>, ncaprisunfan <at> gmail.com,
> 49261 <at> debbugs.gnu.org
> Date: Mon, 12 Jul 2021 19:35:38 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Are we talking about disabling remote locks by default? If so, how
> > about disabling them via a more user-friendly option? It strikes me
> > as weird and un-intuitive to _disable_ something via a "transform"
> > function. And it will definitely be more complex to set up such a
> > "transform" function than just use a boolean flag.
>
> The thing is: In Emacs 27, we didn't have file locking for Tramp files.
> This has now been introduced, and we're discussing how to disable them
> (and only them) in Emacs 28.
>
> Doing that as a transform seems natural, since that's very parallel to
> what we're doing in `auto-save-file-name-transforms' (where Tramp file
> names are made local).
I suggested a compromise: disable it by default, but not via the
transform function. I think it's more natural, but even if you
disagree, would it do as a compromise?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Mon, 12 Jul 2021 18:01:01 GMT)
Full text and
rfc822 format available.
Message #263 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I suggested a compromise: disable it by default, but not via the
> transform function. I think it's more natural, but even if you
> disagree, would it do as a compromise?
I'm OK with another user option to disable it, it doesn't matter too
much. But I'm not sure whether we shall disable it by default: nobody(*)
will enable it ever, and all the effort would be wasted.
(*): except me, of course :-)
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Mon, 12 Jul 2021 18:26:01 GMT)
Full text and
rfc822 format available.
Message #266 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, ncaprisunfan <at> gmail.com,
> 49261 <at> debbugs.gnu.org
> Date: Mon, 12 Jul 2021 20:00:34 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I suggested a compromise: disable it by default, but not via the
> > transform function. I think it's more natural, but even if you
> > disagree, would it do as a compromise?
>
> I'm OK with another user option to disable it, it doesn't matter too
> much. But I'm not sure whether we shall disable it by default: nobody(*)
> will enable it ever, and all the effort would be wasted.
Now _I_ am confused: didn't you say that we _should_ disable it by
default for remote files, because that was how Emacs worked until now?
Or what did I miss?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Mon, 12 Jul 2021 18:48:01 GMT)
Full text and
rfc822 format available.
Message #269 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > I suggested a compromise: disable it by default, but not via the
>> > transform function. I think it's more natural, but even if you
>> > disagree, would it do as a compromise?
>>
>> I'm OK with another user option to disable it, it doesn't matter too
>> much. But I'm not sure whether we shall disable it by default: nobody(*)
>> will enable it ever, and all the effort would be wasted.
>
> Now _I_ am confused: didn't you say that we _should_ disable it by
> default for remote files, because that was how Emacs worked until now?
> Or what did I miss?
No. I meant we shall provide the *possibility* to disable it, because it
didn't exist before.
If I have written something which reads different, it is because of my
limited English.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Mon, 12 Jul 2021 19:05:02 GMT)
Full text and
rfc822 format available.
Message #272 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: larsi <at> gnus.org, ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org
> Date: Mon, 12 Jul 2021 20:46:57 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> > I suggested a compromise: disable it by default, but not via the
> >> > transform function. I think it's more natural, but even if you
> >> > disagree, would it do as a compromise?
> >>
> >> I'm OK with another user option to disable it, it doesn't matter too
> >> much. But I'm not sure whether we shall disable it by default: nobody(*)
> >> will enable it ever, and all the effort would be wasted.
> >
> > Now _I_ am confused: didn't you say that we _should_ disable it by
> > default for remote files, because that was how Emacs worked until now?
> > Or what did I miss?
>
> No. I meant we shall provide the *possibility* to disable it, because it
> didn't exist before.
Ah, okay. I only said it should be disabled by default because I
thought that was what you suggested. I have no problem whatsoever to
have remote locking enabled by default.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Tue, 13 Jul 2021 16:32:02 GMT)
Full text and
rfc822 format available.
Message #275 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I suggested a compromise: disable it by default, but not via the
> transform function. I think it's more natural, but even if you
> disagree, would it do as a compromise?
I don't mind adding a special Tramp variable here (perhaps there should
be one for auto save file names, too, for symmetry)?
But I do think allowing people to inhibit locks/auto save files on a
path name basis is good functionality in general, Tramp no Tramp.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Tue, 13 Jul 2021 16:32:03 GMT)
Full text and
rfc822 format available.
Message #278 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> But I do think allowing people to inhibit locks/auto save files on a
> path name basis is good functionality in general, Tramp no Tramp.
(The last bit should be "Tramp or no Tramp".)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Tue, 13 Jul 2021 16:42:02 GMT)
Full text and
rfc822 format available.
Message #281 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: michael.albinus <at> gmx.de, ncaprisunfan <at> gmail.com, 49261 <at> debbugs.gnu.org
> Date: Tue, 13 Jul 2021 18:30:58 +0200
>
> But I do think allowing people to inhibit locks/auto save files on a
> path name basis is good functionality in general, Tramp no Tramp.
What would a lock-file-name-transforms look like that inhibits file
locking?
And apart of remote file names, what other practical use cases can you
think of where disabling locking selectively based on the file name
would make sense?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Tue, 13 Jul 2021 17:54:01 GMT)
Full text and
rfc822 format available.
Message #284 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> >> I'm OK with another user option to disable it, it doesn't matter too
>> >> much. But I'm not sure whether we shall disable it by default: nobody(*)
>> >> will enable it ever, and all the effort would be wasted.
>> >
>> > Now _I_ am confused: didn't you say that we _should_ disable it by
>> > default for remote files, because that was how Emacs worked until now?
>> > Or what did I miss?
>>
>> No. I meant we shall provide the *possibility* to disable it, because it
>> didn't exist before.
>
> Ah, okay. I only said it should be disabled by default because I
> thought that was what you suggested. I have no problem whatsoever to
> have remote locking enabled by default.
Finally, I've added `remote-file-name-inhibit-locks'. The name shall
look similar to the existing `remote-file-name-inhibit-cache'.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Tue, 13 Jul 2021 17:57:02 GMT)
Full text and
rfc822 format available.
Message #287 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>> I suggested a compromise: disable it by default, but not via the
>> transform function. I think it's more natural, but even if you
>> disagree, would it do as a compromise?
>
> I don't mind adding a special Tramp variable here (perhaps there should
> be one for auto save file names, too, for symmetry)?
>
> But I do think allowing people to inhibit locks/auto save files on a
> path name basis is good functionality in general, Tramp no Tramp.
Well, there is auto-save-mode, which works over the current buffer. Maybe
we could use something similar for file locks?
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Tue, 13 Jul 2021 18:00:02 GMT)
Full text and
rfc822 format available.
Message #290 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
> And apart of remote file names, what other practical use cases can you
> think of where disabling locking selectively based on the file name
> would make sense?
All file names which match `mounted-file-systems'.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Tue, 13 Jul 2021 19:01:01 GMT)
Full text and
rfc822 format available.
Message #293 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, ncaprisunfan <at> gmail.com,
> 49261 <at> debbugs.gnu.org
> Date: Tue, 13 Jul 2021 19:59:12 +0200
>
> > And apart of remote file names, what other practical use cases can you
> > think of where disabling locking selectively based on the file name
> > would make sense?
>
> All file names which match `mounted-file-systems'.
Shouldn't file locking be disabled there by default, and never
enabled?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Tue, 13 Jul 2021 19:06:02 GMT)
Full text and
rfc822 format available.
Message #296 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> Well, there is auto-save-mode, which works over the current buffer. Maybe
> we could use something similar for file locks?
Yeah, I think that's a good idea (but in addition to disabling based on
file name regexps).
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Tue, 13 Jul 2021 19:10:01 GMT)
Full text and
rfc822 format available.
Message #299 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > And apart of remote file names, what other practical use cases can you
>> > think of where disabling locking selectively based on the file name
>> > would make sense?
>>
>> All file names which match `mounted-file-systems'.
>
> Shouldn't file locking be disabled there by default, and never
> enabled?
Disabling file locking there (and backup files too, perhaps?) would make
sense, but the user should be able to override it. (They may have
directories called "/media" that's not a mounted file system.)
As for other use cases -- I have, for instance, some automated processes
on several systems that write to the same file, and file locking of that
file has tripped me up before. I've now rewritten those processes to
work differently, but if `lock-file-name-transforms' had existed before
(and allowed disabling locking based on regexps) I would have used that
instead.
I'm sure there's as many use cases for disabling auto-save/locking based
on regexps as there are for transforming the file names.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Tue, 13 Jul 2021 19:37:02 GMT)
Full text and
rfc822 format available.
Message #302 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > And apart of remote file names, what other practical use cases can you
>> > think of where disabling locking selectively based on the file name
>> > would make sense?
>>
>> All file names which match `mounted-file-systems'.
>
> Shouldn't file locking be disabled there by default, and never
> enabled?
Don't know. At least now, it isn't disabled, and people do not protest.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Tue, 13 Jul 2021 23:13:02 GMT)
Full text and
rfc822 format available.
Message #305 received at 49261 <at> debbugs.gnu.org (full text, mbox):
On 7/12/21 10:54 AM, Eli Zaretskii wrote:
> Then what is the -Woverflow option for? Can you show an example of
> code which -Woverflow would flag that doesn't produce a bogus warning?
Sure: the GCC documentation says -Woverflow is supposed to warn about
"compile-time overflow in constant expressions". So GCC should (and
does) warn about this top-level declaration:
int x = INT_MAX + 1;
However, there is no overflow here:
unsigned a = -1, b = INT_MIN, c = LLONG_MAX;
and these declarations have well-defined behavior in C, so -Woverflow
should not issue warnings for them even though they are unsigned
conversions that change numeric values.
It might be useful to some programmers to generate warnings about these
unsigned conversions, but this should be a separate -W option not
-Woverflow. There's no overflow here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 14 Jul 2021 07:43:02 GMT)
Full text and
rfc822 format available.
Message #308 received at 49261 <at> debbugs.gnu.org (full text, mbox):
On Jul 13 2021, Paul Eggert wrote:
> However, there is no overflow here:
>
> unsigned a = -1, b = INT_MIN, c = LLONG_MAX;
>
> and these declarations have well-defined behavior in C,
This is a bogus argument. You can write total bullshit by using only
well-defined C. And assinging a wider constant to a narrow object,
losing bits, is likely hiding a bug.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 14 Jul 2021 12:37:02 GMT)
Full text and
rfc822 format available.
Message #311 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> Cc: larsi <at> gnus.org, 49261 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Tue, 13 Jul 2021 18:12:00 -0500
>
> On 7/12/21 10:54 AM, Eli Zaretskii wrote:
> > Then what is the -Woverflow option for? Can you show an example of
> > code which -Woverflow would flag that doesn't produce a bogus warning?
>
> Sure: the GCC documentation says -Woverflow is supposed to warn about
> "compile-time overflow in constant expressions". So GCC should (and
> does) warn about this top-level declaration:
>
> int x = INT_MAX + 1;
>
> However, there is no overflow here:
>
> unsigned a = -1, b = INT_MIN, c = LLONG_MAX;
You are saying that there's some fundamental difference between
INT_MAX + 1
and
(USE_LSB_TAG ? - (1 << GCTYPEBITS) : VAL_MAX)
? Or between an expression 'x = FOO' and 'mask = BAR'? I don't see
any fundamental difference. IMO, the warning was valid, as the
assignment loses significant bits.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 14 Jul 2021 22:05:02 GMT)
Full text and
rfc822 format available.
Message #314 received at 49261 <at> debbugs.gnu.org (full text, mbox):
On 7/14/21 2:42 AM, Andreas Schwab wrote:
> On Jul 13 2021, Paul Eggert wrote:
>
>> However, there is no overflow here:
>>
>> unsigned a = -1, b = INT_MIN, c = LLONG_MAX;
>>
>> and these declarations have well-defined behavior in C,
> This is a bogus argument.
It's not bogus. I quoted the GCC documentation and noted that GCC's
behavior does not match its documentation. At the very least -- even if
you like GCC's behavior, which I don't -- the documentation should match
the behavior.
> assinging a wider constant to a narrow object,
> losing bits, is likely hiding a bug.
If that's what you think -Woverflow should do, then GCC doesn't do that
either. For example:
unsigned char a = -1, b = 255;
This generates no warning with -Woverflow, even though A's
initialization assigns a wider constant to a narrow object, losing bits.
Without looking at GCC's source code, it's not clear what -Woverflow
actually does. It is a bit of a mess. Certainly -Woverflow does not do
what it's documented to do.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 14 Jul 2021 22:11:01 GMT)
Full text and
rfc822 format available.
Message #317 received at 49261 <at> debbugs.gnu.org (full text, mbox):
On Jul 14 2021, Paul Eggert wrote:
> This generates no warning with -Woverflow, even though A's initialization
> assigns a wider constant to a narrow object, losing bits.
This is always safe.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Wed, 14 Jul 2021 22:25:01 GMT)
Full text and
rfc822 format available.
Message #320 received at 49261 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 7/14/21 7:36 AM, Eli Zaretskii wrote:
> You are saying that there's some fundamental difference between
>
> INT_MAX + 1
>
> and
>
> (USE_LSB_TAG ? - (1 << GCTYPEBITS) : VAL_MAX)
Yes there's a fundamental difference. INT_MAX + 1 has a signed integer
overflow that violates the C standard. Obviously GCC should diagnose it.
The other expression conforms to the C standard and there is no error or
overflow there. There's no reason -Woverflow should provoke a diagnostic
for it.
> Or between an expression 'x = FOO' and 'mask = BAR'?
I don't know what x, mask, FOO, and BAR refer to.
> the warning was valid, as the
> assignment loses significant bits.
I originally wrote it as "uintptr_t mask = VALMASK;" because I would
rather avoid C casts when possible (they're too powerful and allow too
many bugs to go undetected). I dislike the workaround that I installed
because of (a) its unnecessary cast and (b) the lack of clarity that
it's intended that we want to discard any bits outside UINTPTR_MAX ((b)
was a problem with my original code too).
To try to fix both (a) and (b) I installed the attached further patch.
It is a bit more verbose than what C requires, but the verbosity should
help explain that masking with UINTPTR_MAX is intended, and the
verbosity shouldn't hurt efficiency.
[0001-Pacify-gcc-Woverflow-more-clearly.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Thu, 15 Jul 2021 06:15:01 GMT)
Full text and
rfc822 format available.
Message #323 received at 49261 <at> debbugs.gnu.org (full text, mbox):
> Cc: larsi <at> gnus.org, 49261 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Wed, 14 Jul 2021 17:24:37 -0500
>
> I originally wrote it as "uintptr_t mask = VALMASK;" because I would
> rather avoid C casts when possible (they're too powerful and allow too
> many bugs to go undetected). I dislike the workaround that I installed
> because of (a) its unnecessary cast and (b) the lack of clarity that
> it's intended that we want to discard any bits outside UINTPTR_MAX ((b)
> was a problem with my original code too).
>
> To try to fix both (a) and (b) I installed the attached further patch.
> It is a bit more verbose than what C requires, but the verbosity should
> help explain that masking with UINTPTR_MAX is intended, and the
> verbosity shouldn't hurt efficiency.
Thanks, I think this new code is much cleaner and less mysterious.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Fri, 16 Jul 2021 16:17:01 GMT)
Full text and
rfc822 format available.
Message #326 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
Hi Lars,
>> Well, there is auto-save-mode, which works over the current buffer. Maybe
>> we could use something similar for file locks?
>
> Yeah, I think that's a good idea (but in addition to disabling based on
> file name regexps).
I've pushed this to master.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#49261; Package
emacs.
(Sat, 17 Jul 2021 14:07:02 GMT)
Full text and
rfc822 format available.
Message #329 received at 49261 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> I've pushed this to master.
Great! I think we've covered this bug report, then, and I'm closing it.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug marked as fixed in version 28.1, send any further explanations to
49261 <at> debbugs.gnu.org and Mallchad Skeghyeph <ncaprisunfan <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sat, 17 Jul 2021 14:07:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 15 Aug 2021 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 248 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.