* bug#66375: 30.0.50; (error "Maximum buffer size exceeded") from (insert-file-contents "/dev/null")
@ 2023-10-06 17:11 Sam Steingold
2023-10-07 5:54 ` Eli Zaretskii
2023-12-14 16:46 ` Ed Santiago
0 siblings, 2 replies; 12+ messages in thread
From: Sam Steingold @ 2023-10-06 17:11 UTC (permalink / raw)
To: 66375
emacs -Q
(insert-file-contents "/dev/null")
==>
Debugger entered--Lisp error: (error "Maximum buffer size exceeded")
insert-file-contents("/dev/null")
In GNU Emacs 30.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.33, cairo version 1.16.0) of 2023-10-06 built on pop-os
Repository revision: 505c80623049d9e181918acdac8229c9a2041b1e
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Pop!_OS 22.04 LTS
Configured using:
'configure --with-mailutils --with-native-compilation
--with-imagemagick'
Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ IMAGEMAGICK
JPEG JSON LCMS2 LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB
Important settings:
value of $LC_COLLATE: C
value of $LANG: C
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Fundamental
Minor modes in effect:
pyvenv-mode: t
global-atomic-chrome-edit-mode: t
global-edit-server-edit-mode: t
server-mode: t
winner-mode: t
which-function-mode: t
url-handler-mode: t
desktop-save-mode: t
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-regexp-mode: t
column-number-mode: t
line-number-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Memory information:
((conses 16 1197252 211019) (symbols 48 35274 49) (strings 32 325111 14525)
(string-bytes 1 9424577) (vectors 16 159905) (vector-slots 8 2352900 163968)
(floats 8 927 484) (intervals 56 9746 2819) (buffers 992 73))
--
Sam Steingold (https://aphar.dreamwidth.org/) on Pop 22.04 (jammy) X 11.0.12101004
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://iris.org.il https://honestreporting.com https://mideasttruth.com
Any connection between your reality and mine is purely coincidental.
^ permalink raw reply [flat|nested] 12+ messages in thread* bug#66375: 30.0.50; (error "Maximum buffer size exceeded") from (insert-file-contents "/dev/null") 2023-10-06 17:11 bug#66375: 30.0.50; (error "Maximum buffer size exceeded") from (insert-file-contents "/dev/null") Sam Steingold @ 2023-10-07 5:54 ` Eli Zaretskii 2023-10-07 6:43 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-10-09 1:57 ` Sam Steingold 2023-12-14 16:46 ` Ed Santiago 1 sibling, 2 replies; 12+ messages in thread From: Eli Zaretskii @ 2023-10-07 5:54 UTC (permalink / raw) To: sds, Po Lu, Paul Eggert; +Cc: 66375 > From: Sam Steingold <sds@gnu.org> > Date: Fri, 06 Oct 2023 13:11:35 -0400 > > > emacs -Q > > (insert-file-contents "/dev/null") > ==> > Debugger entered--Lisp error: (error "Maximum buffer size exceeded") > insert-file-contents("/dev/null") This is a "feature". From the doc string: When inserting data from a special file (e.g., /dev/urandom), you can’t specify VISIT or BEG, and END should be specified to avoid inserting unlimited data into the buffer from some special files which otherwise could supply infinite amounts of data. Maybe we could make a special exception for the null-device, whose name we generally know on each supported system. Technically, the problem is that the null device is seekable, so this: if (seekable || !NILP (end)) total = end_offset - beg_offset; computes 'total' to be a very large value, and then this: /* Ensure the gap is at least one byte larger than needed for the estimated file size, so that in the usual case we read to EOF without reallocating. */ if (GAP_SIZE <= total) make_gap (total - GAP_SIZE + 1); attempts to make a gap very large, which errors out. And that is before we try to read even a single byte from the file. Po Lu and Paul, any ideas? ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66375: 30.0.50; (error "Maximum buffer size exceeded") from (insert-file-contents "/dev/null") 2023-10-07 5:54 ` Eli Zaretskii @ 2023-10-07 6:43 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-10-07 7:43 ` Eli Zaretskii 2023-10-09 1:57 ` Sam Steingold 1 sibling, 1 reply; 12+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-07 6:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: sds, 66375, Paul Eggert Eli Zaretskii <eliz@gnu.org> writes: >> From: Sam Steingold <sds@gnu.org> >> Date: Fri, 06 Oct 2023 13:11:35 -0400 >> >> >> emacs -Q >> >> (insert-file-contents "/dev/null") >> ==> >> Debugger entered--Lisp error: (error "Maximum buffer size exceeded") >> insert-file-contents("/dev/null") > > This is a "feature". From the doc string: > > When inserting data from a special file (e.g., /dev/urandom), you > can’t specify VISIT or BEG, and END should be specified to avoid > inserting unlimited data into the buffer from some special files > which otherwise could supply infinite amounts of data. > > Maybe we could make a special exception for the null-device, whose > name we generally know on each supported system. > > Technically, the problem is that the null device is seekable, so this: > > if (seekable || !NILP (end)) > total = end_offset - beg_offset; > > computes 'total' to be a very large value, and then this: > > /* Ensure the gap is at least one byte larger than needed for the > estimated file size, so that in the usual case we read to EOF > without reallocating. */ > if (GAP_SIZE <= total) > make_gap (total - GAP_SIZE + 1); > > attempts to make a gap very large, which errors out. And that is > before we try to read even a single byte from the file. > > Po Lu and Paul, any ideas? I think treating /dev/null specially is suitable, but there is a different shortcoming in the approach presently taken by insert-file-contents: if (!regular) end_offset = TYPE_MAXIMUM (off_t); else { end_offset = st.st_size; I think that the code computing total is presently beset by a presumption that special files are uniformly non-seekable and loses if that assumption proves untrue. Perhaps it should disregard end_offset if isn't expressly provided by the caller and the file is special, which if true implies that end_offset is TYPE_MAXIMUM (off_t); much as in the following untested patch: diff --git a/src/fileio.c b/src/fileio.c index 8919e08e1fd..e09616fb337 100644 --- a/src/fileio.c +++ b/src/fileio.c @@ -4746,7 +4746,7 @@ DEFUN ("insert-file-contents", Finsert_file_contents, Sinsert_file_contents, goto handled; } - if (seekable || !NILP (end)) + if (((regular || !NILP (end)) && seekable) || !NILP (end)) total = end_offset - beg_offset; else /* For a special file, all we can do is guess. */ ^ permalink raw reply related [flat|nested] 12+ messages in thread
* bug#66375: 30.0.50; (error "Maximum buffer size exceeded") from (insert-file-contents "/dev/null") 2023-10-07 6:43 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-07 7:43 ` Eli Zaretskii 0 siblings, 0 replies; 12+ messages in thread From: Eli Zaretskii @ 2023-10-07 7:43 UTC (permalink / raw) To: Po Lu; +Cc: sds, 66375, eggert > From: Po Lu <luangruo@yahoo.com> > Cc: sds@gnu.org, Paul Eggert <eggert@cs.ucla.edu>, 66375@debbugs.gnu.org > Date: Sat, 07 Oct 2023 14:43:45 +0800 > > --- a/src/fileio.c > +++ b/src/fileio.c > @@ -4746,7 +4746,7 @@ DEFUN ("insert-file-contents", Finsert_file_contents, Sinsert_file_contents, > goto handled; > } > > - if (seekable || !NILP (end)) > + if (((regular || !NILP (end)) && seekable) || !NILP (end)) > total = end_offset - beg_offset; > else > /* For a special file, all we can do is guess. */ > This does a couple of redundant tests: . regular non-zero means seekable must be non-zero . NILP (end) is tested twice for now good reason I think the above should be cleaned up to better understand the logic. More generally, I think 'total' should not be computed in this naïve way when end_offset is -1, i.e. unless end_offset is either the result of fstat/stat or the result of actually seeking to the end of file/device. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66375: 30.0.50; (error "Maximum buffer size exceeded") from (insert-file-contents "/dev/null") 2023-10-07 5:54 ` Eli Zaretskii 2023-10-07 6:43 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-10-09 1:57 ` Sam Steingold 2023-10-09 10:56 ` Eli Zaretskii 1 sibling, 1 reply; 12+ messages in thread From: Sam Steingold @ 2023-10-09 1:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Po Lu, Paul Eggert, 66375 On Sat, 7 Oct 2023 at 01:54, Eli Zaretskii <eliz@gnu.org> wrote: > > > From: Sam Steingold <sds@gnu.org> > > Date: Fri, 06 Oct 2023 13:11:35 -0400 > > emacs -Q > > > > (insert-file-contents "/dev/null") > > ==> > > Debugger entered--Lisp error: (error "Maximum buffer size exceeded") > > insert-file-contents("/dev/null") > > This is a "feature". this is new behavior. I used /dev/null as "empty gnu score file since forever" -- Sam Steingold <http://sds.podval.org> <http://www.childpsy.net> <http://steingoldpsychology.com> ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66375: 30.0.50; (error "Maximum buffer size exceeded") from (insert-file-contents "/dev/null") 2023-10-09 1:57 ` Sam Steingold @ 2023-10-09 10:56 ` Eli Zaretskii 2023-10-15 15:43 ` Sam Steingold 0 siblings, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2023-10-09 10:56 UTC (permalink / raw) To: Sam Steingold; +Cc: luangruo, eggert, 66375 > From: Sam Steingold <sds@gnu.org> > Date: Sun, 8 Oct 2023 21:57:02 -0400 > Cc: Po Lu <luangruo@yahoo.com>, Paul Eggert <eggert@cs.ucla.edu>, 66375@debbugs.gnu.org > > On Sat, 7 Oct 2023 at 01:54, Eli Zaretskii <eliz@gnu.org> wrote: > > > > > From: Sam Steingold <sds@gnu.org> > > > Date: Fri, 06 Oct 2023 13:11:35 -0400 > > > emacs -Q > > > > > > (insert-file-contents "/dev/null") > > > ==> > > > Debugger entered--Lisp error: (error "Maximum buffer size exceeded") > > > insert-file-contents("/dev/null") > > > > This is a "feature". > > this is new behavior. > I used /dev/null as "empty gnu score file since forever" You still can do that, you just need to use a non-nil END argument. And maybe we will find a better solution. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66375: 30.0.50; (error "Maximum buffer size exceeded") from (insert-file-contents "/dev/null") 2023-10-09 10:56 ` Eli Zaretskii @ 2023-10-15 15:43 ` Sam Steingold 2023-10-15 16:33 ` Eli Zaretskii 0 siblings, 1 reply; 12+ messages in thread From: Sam Steingold @ 2023-10-15 15:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, eggert, 66375 I am not sure what you mean here, sorry. I am unable to use Gnus because of this new bug. On Mon, 9 Oct 2023 at 06:57, Eli Zaretskii <eliz@gnu.org> wrote: > > > From: Sam Steingold <sds@gnu.org> > > Date: Sun, 8 Oct 2023 21:57:02 -0400 > > Cc: Po Lu <luangruo@yahoo.com>, Paul Eggert <eggert@cs.ucla.edu>, 66375@debbugs.gnu.org > > > > On Sat, 7 Oct 2023 at 01:54, Eli Zaretskii <eliz@gnu.org> wrote: > > > > > > > From: Sam Steingold <sds@gnu.org> > > > > Date: Fri, 06 Oct 2023 13:11:35 -0400 > > > > emacs -Q > > > > > > > > (insert-file-contents "/dev/null") > > > > ==> > > > > Debugger entered--Lisp error: (error "Maximum buffer size exceeded") > > > > insert-file-contents("/dev/null") > > > > > > This is a "feature". > > > > this is new behavior. > > I used /dev/null as "empty gnu score file since forever" > > You still can do that, you just need to use a non-nil END argument. > > And maybe we will find a better solution. -- Sam Steingold <http://sds.podval.org> <http://www.childpsy.net> <http://steingoldpsychology.com> ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66375: 30.0.50; (error "Maximum buffer size exceeded") from (insert-file-contents "/dev/null") 2023-10-15 15:43 ` Sam Steingold @ 2023-10-15 16:33 ` Eli Zaretskii 2023-10-15 16:44 ` Sam Steingold 0 siblings, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2023-10-15 16:33 UTC (permalink / raw) To: Sam Steingold; +Cc: luangruo, eggert, 66375 > From: Sam Steingold <sds@gnu.org> > Date: Sun, 15 Oct 2023 11:43:24 -0400 > Cc: luangruo@yahoo.com, eggert@cs.ucla.edu, 66375@debbugs.gnu.org > > I am not sure what you mean here, sorry. > I am unable to use Gnus because of this new bug. Where does Gnus do something like that? We can at least install a quick workaround if you can tell where is this code in Gnus. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66375: 30.0.50; (error "Maximum buffer size exceeded") from (insert-file-contents "/dev/null") 2023-10-15 16:33 ` Eli Zaretskii @ 2023-10-15 16:44 ` Sam Steingold 2023-10-15 18:22 ` Eli Zaretskii 0 siblings, 1 reply; 12+ messages in thread From: Sam Steingold @ 2023-10-15 16:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, eggert, 66375 When I enter a group for which I set score file to nil or /dev/null in gnus-score-file-single-match-alist I get this: Debugger entered--Lisp error: (error "Maximum buffer size exceeded") insert-file-contents("/dev/null") gnus-score-load-score-alist("/dev/null") gnus-score-load-file("/dev/null") gnus-score-load-files(("/home/sds/.gnus-kill/new-thread" "/home/sds/.gnus-kill/lisp" "/dev/null" nil "/home/sds/.gnus-kill/non-ascii" "/home/sds/.gnus-kill/all" "/home/sds/.gnus-kill/gmane" "/home/sds/.gnus-kill/gnu" "/home/sds/.gnus-kill/emacs")) gnus-score-headers(("/home/sds/.gnus-kill/new-thread" "/home/sds/.gnus-kill/lisp" "/dev/null" nil "/home/sds/.gnus-kill/non-ascii" "/home/sds/.gnus-kill/all" "/home/sds/.gnus-kill/gmane" "/home/sds/.gnus-kill/gnu" "/home/sds/.gnus-kill/emacs") nil) gnus-possibly-score-headers() gnus-summary-read-group-1("nntp+news.gwene.org:gmane.emacs.bbdb.user" nil t nil nil nil) gnus-summary-read-group("nntp+news.gwene.org:gmane.emacs.bbdb.user" nil t nil nil nil nil) gnus-group-read-group(nil t) gnus-group-select-group(nil) funcall-interactively(gnus-group-select-group nil) command-execute(gnus-group-select-group) On Sun, 15 Oct 2023 at 12:33, Eli Zaretskii <eliz@gnu.org> wrote: > > > From: Sam Steingold <sds@gnu.org> > > Date: Sun, 15 Oct 2023 11:43:24 -0400 > > Cc: luangruo@yahoo.com, eggert@cs.ucla.edu, 66375@debbugs.gnu.org > > > > I am not sure what you mean here, sorry. > > I am unable to use Gnus because of this new bug. > > Where does Gnus do something like that? We can at least install a > quick workaround if you can tell where is this code in Gnus. -- Sam Steingold <http://sds.podval.org> <http://www.childpsy.net> <http://steingoldpsychology.com> ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66375: 30.0.50; (error "Maximum buffer size exceeded") from (insert-file-contents "/dev/null") 2023-10-15 16:44 ` Sam Steingold @ 2023-10-15 18:22 ` Eli Zaretskii 0 siblings, 0 replies; 12+ messages in thread From: Eli Zaretskii @ 2023-10-15 18:22 UTC (permalink / raw) To: Sam Steingold; +Cc: luangruo, eggert, 66375 > From: Sam Steingold <sds@gnu.org> > Date: Sun, 15 Oct 2023 12:44:18 -0400 > Cc: luangruo@yahoo.com, eggert@cs.ucla.edu, 66375@debbugs.gnu.org > > When I enter a group for which I set score file to nil or /dev/null in > gnus-score-file-single-match-alist > I get this: > > Debugger entered--Lisp error: (error "Maximum buffer size exceeded") > insert-file-contents("/dev/null") > gnus-score-load-score-alist("/dev/null") > gnus-score-load-file("/dev/null") gnus-score-file-single-match-alist is a defcustom, so you could replace "/dev/null" in the alist with some real file that is empty, couldn't you? ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66375: 30.0.50; (error "Maximum buffer size exceeded") from (insert-file-contents "/dev/null") 2023-10-06 17:11 bug#66375: 30.0.50; (error "Maximum buffer size exceeded") from (insert-file-contents "/dev/null") Sam Steingold 2023-10-07 5:54 ` Eli Zaretskii @ 2023-12-14 16:46 ` Ed Santiago 2023-12-14 18:43 ` Eli Zaretskii 1 sibling, 1 reply; 12+ messages in thread From: Ed Santiago @ 2023-12-14 16:46 UTC (permalink / raw) To: 66375 Another reproducer, somewhat more common than /dev/null: $ emacs --insert <(date) "date" is trivial, but '<(some-command-that-produces-output)' is a common pattern. Emacs 29 breaks this. ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#66375: 30.0.50; (error "Maximum buffer size exceeded") from (insert-file-contents "/dev/null") 2023-12-14 16:46 ` Ed Santiago @ 2023-12-14 18:43 ` Eli Zaretskii 0 siblings, 0 replies; 12+ messages in thread From: Eli Zaretskii @ 2023-12-14 18:43 UTC (permalink / raw) To: Ed Santiago; +Cc: 66375 > From: Ed Santiago <bug-emacs@edsantiago.com> > Phone: 1-505-662-5142 > Date: Thu, 14 Dec 2023 09:46:32 -0700 > > Another reproducer, somewhat more common than /dev/null: > > $ emacs --insert <(date) > > "date" is trivial, but '<(some-command-that-produces-output)' is > a common pattern. Emacs 29 breaks this. The issue with '<(some-command-that-produces-output)' is already fixed on the emacs-29 branch, so it is no longer part of this bug report. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-12-14 18:43 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-10-06 17:11 bug#66375: 30.0.50; (error "Maximum buffer size exceeded") from (insert-file-contents "/dev/null") Sam Steingold 2023-10-07 5:54 ` Eli Zaretskii 2023-10-07 6:43 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2023-10-07 7:43 ` Eli Zaretskii 2023-10-09 1:57 ` Sam Steingold 2023-10-09 10:56 ` Eli Zaretskii 2023-10-15 15:43 ` Sam Steingold 2023-10-15 16:33 ` Eli Zaretskii 2023-10-15 16:44 ` Sam Steingold 2023-10-15 18:22 ` Eli Zaretskii 2023-12-14 16:46 ` Ed Santiago 2023-12-14 18:43 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).