From: Ken Brown <kbrown@cornell.edu>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: lekktu@gmail.com, schwab@linux-m68k.org,
Richard Stallman <rms@gnu.org>,
11519@debbugs.gnu.org
Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping
Date: Wed, 23 May 2012 11:23:21 -0400 [thread overview]
Message-ID: <4FBD00E9.1060401@cornell.edu> (raw)
In-Reply-To: <jwvtxz7f1gc.fsf-monnier+emacs@gnu.org>
On 5/23/2012 10:16 AM, Stefan Monnier wrote:
>> Which other places use C pointers to buffer text and call functions
>> that can allocate memory?
>
> IIUC any place that uses STRING_CHAR_AND_LENGTH on buffer text is
> vulnerable to the problem.
>
>> Anyway, are you against committing this to the release branch? I'd be
>> very sad if you were, having invested so much time in hunting this
>> bug, but I guess I'll survive.
>
> I'm not dead set against it, and I'm glad we found the culprit so we can
> fix it: fixing it on the release branch is not that important, since this
> bug has been with us since Emacs-23.1, AFAICT.
>
> If you really want to install your workaround on the emacs-24 branch, go
> for it but let's try to find a real fix for the trunk.
>
>>>>> I wonder: why do we use REL_ALLOC?
>>>> AFAIK, we do that only on platforms that don't support mmap for
>>>> allocating buffer text.
>>> So, IIUC the only reason to use it is so that we can more often return
>>> memory to the OS even for the non-mmap case? Is that because returning
>>> memory can only be done via sbrk style memory management?
>> I don't think this is only about _returning_ memory. It is first and
>> foremost about not _asking_ for more memory when we can come up with
>> it by reshuffling buffer text.
>
> So you're saying it's use for fragmentation reasons?
> But on other platforms where we use mmap, we do suffer from this
> fragmentation, and yet it doesn't seem to be a real source of problem.
> That's why I think the only real reason is because memory can only be
> returned via sbrk-style memory management (i.e. only free memory at the
> end of the heap can be returned). Is that right?
>
> I guess my question turns into "why do we use gmalloc.c instead of
> a malloc library that uses mmap (or some other mechanism that lets it
> return large free chunks to the OS)"?
>
> AFAIK, Windows is pretty much the only system where we use gmalloc.c and
> ralloc.c nowadays. Does anyone remember why we don't use the system
> malloc under Windows (and Cygwin)?
Cygwin uses gmalloc.c but not ralloc.c; it uses mmap for buffers. There
are two reasons for using gmalloc.c on Cygwin. The first, which may or
may not be important, is that Cygwin's malloc doesn't support
__after_morecore_hook, malloc_get_state, or malloc_set_state. The
second has to do with the way emacs is dumped on Cygwin. See the
comment starting at line 302 in gmalloc.c.
I would love to find a better way to deal with this and be able to use
the system malloc on Cygwin.
Ken
next prev parent reply other threads:[~2012-05-23 15:23 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-19 16:10 bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Juanma Barranquero
2012-05-19 16:27 ` Eli Zaretskii
2012-05-19 21:40 ` Juanma Barranquero
2012-05-20 17:27 ` Eli Zaretskii
2012-05-20 19:00 ` Juanma Barranquero
2012-05-21 1:50 ` Stefan Monnier
2012-05-21 2:51 ` Eli Zaretskii
2012-05-21 7:59 ` Andreas Schwab
2012-05-21 17:51 ` Eli Zaretskii
2012-05-21 20:39 ` Stefan Monnier
2012-05-22 19:00 ` Eli Zaretskii
2012-05-22 19:19 ` Stefan Monnier
2012-05-22 19:47 ` Eli Zaretskii
2012-05-23 0:47 ` Stefan Monnier
2012-05-23 2:59 ` Eli Zaretskii
2012-05-23 14:16 ` Stefan Monnier
2012-05-23 15:23 ` Ken Brown [this message]
2012-05-23 16:52 ` Eli Zaretskii
2012-05-23 20:07 ` Stefan Monnier
2012-05-24 16:22 ` Eli Zaretskii
2012-05-28 2:15 ` Stefan Monnier
2012-05-28 16:53 ` Eli Zaretskii
2012-05-28 19:44 ` Stefan Monnier
2012-05-28 20:47 ` Eli Zaretskii
2012-05-29 1:23 ` Stefan Monnier
2012-05-29 16:02 ` Eli Zaretskii
2012-06-02 20:44 ` Juanma Barranquero
2012-06-03 4:18 ` Eli Zaretskii
2013-12-28 8:41 ` Glenn Morris
2013-12-28 9:48 ` Eli Zaretskii
2012-05-23 17:34 ` Eli Zaretskii
2012-05-23 14:10 ` Kenichi Handa
2012-05-23 15:27 ` Stefan Monnier
2012-05-23 17:02 ` Eli Zaretskii
2012-05-22 14:38 ` Kenichi Handa
2012-05-22 19:02 ` Eli Zaretskii
2012-05-21 1:49 ` Stefan Monnier
2012-05-21 2:50 ` Eli Zaretskii
2012-05-21 3:21 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FBD00E9.1060401@cornell.edu \
--to=kbrown@cornell.edu \
--cc=11519@debbugs.gnu.org \
--cc=lekktu@gmail.com \
--cc=monnier@iro.umontreal.ca \
--cc=rms@gnu.org \
--cc=schwab@linux-m68k.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.