Re: When should ralloc.c be used?

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  emacs-devel@gnu.org
> Date: Sun, 23 Oct 2016 16:36:24 -0400
> 
> > Then what are our choices to solve this for Emacs 25.2?  If GNU/Linux
> > starts using ralloc more and more, we will have crashes and data
> > corruption all over the place.  It's inconceivable to release 25.2 in
> > this state.
> 
> What's wrong with using gmalloc without ralloc and with mmap'd buffers?

Nothing, if it works.  But someone should set up Emacs to do that, and
make sure the result builds, bootstraps, and works reliably,
i.e. doesn't have all the problems reported recently in this and
related bugs.

I don't have access to any platforms that are affected by this
(fencepost doesn't yet have such a new glibc).  I will do this myself
if no one else comes to help, but I really could use help from people
who work on platforms that are affected by this issue.  Noam and Sam
help, but we need more manpower and more expertise.

In any case, I asked what were our alternatives, because I'm not sure
we have a clear view of those.  Making decisions with just a peephole
view of the issues is never a good idea.  The best solution might not
be changing the configury to eliminate ralloc, it could be something
entirely different.

For example, I see in regex.c a set of special definitions for
REGEX_ALLOCATE_STACK and friends conditioned by this:

  #if defined REL_ALLOC && defined REGEX_MALLOC

These definitions call directly a few functions in ralloc.c, as
opposed to going via malloc.  Does anyone know what is this about?
Should we try building with REGEX_MALLOC on platforms that use
ralloc.c, and see whether the problems with regex searches triggered
by relocation go away?

Yet another idea is enlarge the stack space available to SAFE_ALLOCA
in regex.c, so that the failure stack is allocated off the C runtime
stack, thus side-stepping the relocation issues.

And maybe there are other possibilities.  We really need to come up
with all the possible ideas, try which ones work, and decide as
quickly as possible what is the best one.  This currently is the most
serious blocking issue on the way towards releasing Emacs 25.2 soon,
as we wanted to.