unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Petteri Hintsanen <petterih@iki.fi>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Bindat can exhaust memory when unpacking to vector
Date: Mon, 23 Oct 2023 22:36:01 +0300	[thread overview]
Message-ID: <87a5s9m8ri.fsf@iki.fi> (raw)
In-Reply-To: <83zg09oa1v.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 23 Oct 2023 14:25:16 +0300")

Eli Zaretskii <eliz@gnu.org> writes:

> Hang or just slow down tremendously due to paging?  How much time did
> you wait before deciding that Emacs hung?  And how much memory do you
> have on that machine?

Sorry, I was careless with wording; obviously what I meant was "slowed
down due to paging."  I did not wait for long, maybe a minute or so.
This machine has ample memory, 16 GB RAM plus another 16 GB swap space.

> Can you argue why this should be considered a problem for Emacs to
> solve, and not a cockpit error on the part of the Lisp program that
> makes such calls?

No, not really.  Now when I think about it, it is fairly obvious that
the programmer should realize this when using such low level mechanism
as Bindat.

>> Nonetheless, I think it would be prudent to mention this potential
>> pitfall in the Emacs Lisp manual so that users become aware of it.
>> I can write a texinfo patch if you agree.
>
> What would we say? that unpacking vectors larger than available memory
> would cause Emacs to run out of memory?

I was thinking of some kind of note about validation, e.g.:

  Notice that unpacking data to a vector of length LEN will
  unconditionally preallocate memory with at least LEN bytes.  If LEN is
  calculated from the input, it is a good idea to validate its value
  before unpacking.

But, again, users of Bindat can be expected to know that tainted data
should be sanitized.  And what is described above is an implementation
detail.  So it does not make much sense to mention this in the manual.

Sorry for the noise.
Petteri



  reply	other threads:[~2023-10-23 19:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-22 19:36 Bindat can exhaust memory when unpacking to vector Petteri Hintsanen
2023-10-23 11:25 ` Eli Zaretskii
2023-10-23 19:36   ` Petteri Hintsanen [this message]
2023-10-24  4:34     ` tomas
2023-11-12 19:11       ` Petteri Hintsanen
2023-11-04  7:48     ` Eli Zaretskii
2023-11-04  8:21       ` Stefan Monnier
2024-03-10 21:58         ` Stefan Monnier
2024-03-19 20:09           ` Petteri Hintsanen
2024-03-19 21:08             ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a5s9m8ri.fsf@iki.fi \
    --to=petterih@iki.fi \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).