* 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).