unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: npostavs@users.sourceforge.net
Cc: 26952@debbugs.gnu.org
Subject: bug#26952: 25.1; loops eating all memory while yanking big rectangle
Date: Sat, 20 May 2017 20:59:44 +0300	[thread overview]
Message-ID: <8360gvpfxr.fsf@gnu.org> (raw)
In-Reply-To: <87vaovh1db.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net)

> From: npostavs@users.sourceforge.net
> Cc: 26952@debbugs.gnu.org,  pot@gnu.org
> Date: Sat, 20 May 2017 13:41:36 -0400
> 
> The following simple loop can trigger the issue (I'm now also limiting
> Emacs' memory usage to 1GB with "ulimit -Sv $((1000 * 1024))" so that it
> just throws an out of memory error instead of filling my swap and
> slowing everything down):
> 
>   (let ((str (make-string 150 ?a)))
>     (dotimes (_ (* 600 1000))
>       (insert str ?\n)))
> 
> I think it might be just an inefficient allocater (or this pattern of
> allocation happens to hit a pathological case for the allocater).  The
> master branch is using the 'hybrid' allocater, while emacs-25 is not.
> If I configure 25.2 with REL_ALLOC=yes, then it runs okay.  The only
> allocation seems to be from 'enlarge_buffer_text'.

Thanks.

So you are saying that inserting 90MB worth of text into a buffer
makes Emacs 25.2 run out of 1GB of memory, due to inefficiencies of
the malloc implementation?  (Here on Windows it produces a 230MB Emacs
session, but the Windows build uses the moral equivalent of mmap for
allocating buffer text.)

Maybe we should release Emacs 25.3 with this single problem fixed?





  reply	other threads:[~2017-05-20 17:59 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-16 14:53 bug#26952: 25.1; loops eating all memory while yanking big rectangle Francesco Potortì
2017-05-20  0:24 ` npostavs
2017-05-20  9:59   ` Eli Zaretskii
2017-05-20 17:41     ` npostavs
2017-05-20 17:59       ` Eli Zaretskii [this message]
2017-05-20 19:27         ` npostavs
2017-05-21 15:28           ` Eli Zaretskii
2017-05-21 16:00             ` npostavs
2017-05-21 16:10               ` Eli Zaretskii
2017-05-21 16:48                 ` npostavs
2017-05-21 19:15             ` Paul Eggert
2017-05-21 19:53               ` Eli Zaretskii
2017-05-21 20:20                 ` Paul Eggert
2017-05-21 20:40                   ` npostavs
2017-05-21 20:40                     ` Paul Eggert
2017-05-21 20:52                       ` npostavs
2017-05-22  4:01                   ` Eli Zaretskii
2017-05-25  5:31                     ` John Wiegley
2017-05-25 15:09                       ` Eli Zaretskii
2017-05-25 16:19                         ` Paul Eggert
2017-05-25 16:41                           ` Francesco Potortì
2017-05-25 17:20                           ` Eli Zaretskii
2017-05-27  1:15                             ` Glenn Morris
2017-05-27  6:57                               ` Paul Eggert
2017-05-27  7:42                               ` Eli Zaretskii
2017-05-25 16:48                         ` John Wiegley
2017-05-25 17:18                           ` Noam Postavsky
2017-05-25 17:29                             ` Francesco Potortì
2017-05-25 17:42                               ` Noam Postavsky
2017-05-25 17:45                           ` Eli Zaretskii
2017-05-25 19:24                             ` Paul Eggert
2017-05-25 19:34                               ` Eli Zaretskii
2017-05-25 20:59                                 ` Paul Eggert
2017-05-26  6:25                                   ` Eli Zaretskii
2017-05-26 15:24                                     ` Paul Eggert
2017-05-21 20:06               ` npostavs
2017-05-22  3:58                 ` Eli Zaretskii
2020-01-08 16:45 ` bug#26952: Possible regression of Bug#26952 - "repeated buffer insertion consumes excessive memory" Peter Ludemann
2020-01-09  0:08   ` bug#39045: Fwd: Possible regression " Peter Ludemann
2022-05-23 10:48     ` Lars Ingebrigtsen
2022-06-21 11:46       ` Lars Ingebrigtsen
2020-01-09  0:10   ` bug#26952: Possible regression of Bug#26952 " Peter Ludemann

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=8360gvpfxr.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=26952@debbugs.gnu.org \
    --cc=npostavs@users.sourceforge.net \
    /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).