bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping

[Ken Brown <kbrown@cornell.edu>]

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