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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Kenichi Handa <handa@gnu.org>, schwab@linux-m68k.org, lekktu@gmail.com,
>         11519@debbugs.gnu.org
> Date: Tue, 22 May 2012 15:19:12 -0400
> 
> > Note that the address of buffer text has changed from 0x10757948 to
> > 0x10826948.  And the culprit is ...
> 
> >   #7  0x010397fb in xmalloc (size=786436) at alloc.c:727
> >   #8  0x0120da2d in load_charset_map_from_file (charset=0x1944970,
> >       mapfile=57455953, control_flag=1) at charset.c:501
> 
> Huh!  Indeed, I always assumed that relocation would be something that
> can only happen during GC, not in a mere xmalloc.

It happens in xmalloc/xrealloc when ralloc.c is used.

> > If you agree with the diagnosis, then how about the change below?
> 
> Might be an acceptable workaround for the emacs-24 branch, yes (tho I'd
> replace "inhibit ? 0 : 1" with "!inhibit").  But is it really new in
> Emacs-24?  It seems the same problem is already present in Emacs-23, so
> it's probably not so urgent to fix it for 24.1.

The problem is indeed not new, but so what?  It is real, and it just
happened to us in real life, albeit on the trunk.  Who knows how many
other problems which we dismiss as not reproducible could have been
caused by this (especially when exotic character sets were involved)?

> I wonder: why do we use REL_ALLOC?

AFAIK, we do that only on platforms that don't support mmap for
allocating buffer text.

The relocatable allocator makes a more efficient use of memory,
especially when it is almost full: it can potentially produce a large
block from several small ones by moving buffer text around to
"compact" their storage.