bug#18222: 24.3.92; fork handlers in gmalloc.c can lead to deadlock

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 23 Aug 2014 12:00:08 -0400, Ken Brown <kbrown@cornell.edu> said:

> On 8/11/2014 11:29 AM, Ken Brown wrote:
>> I'm leaving the bug open, since a better fix is needed for the
>> trunk.

> I tried to implement Yamamoto Mitsuharu's suggestion of switching to
> Cygwin's malloc.  I don't see a reasonable way to avoid using
> gmalloc.c before dumping, because I think that would require a major
> rewrite of unexec, and even then I don't see how to do it.  But it
> turns out to be easy to make the dumped emacs use Cygwin's malloc,
> and this seems to solve all the problems with gmalloc.c that I'm
> aware of (patch attached).  In particular, there's no need to worry
> about making malloc thread-safe.

> Most of what's needed for this is not Cygwin-specific, so I've tried
> to write it in a general way on the off chance that it's useful for
> other platforms that use gmalloc.  I've defined a new macro
> HYBRID_MALLOC that means "use gmalloc before dumping and the system
> malloc after dumping".  All the Cygwin-specific code occurs in the
> definitions of two macros, DUMPED and ALLOCATED_BEFORE_DUMPING, in
> gmalloc.c.

> The patch still needs a lot more testing, but I'd like to know if
> people think my approach is reasonable.  Comments and suggestions
> would be appreciated.  I would also appreciate it if people who
> build emacs on Cygwin would test the patch.

I think it's worth trying also on other platforms that use gmalloc.
IIRC, the main reason why *BSDs are using gmalloc is their system
mallocs are not compatible with unexec.

One drawback of this approach is it makes it impossible to dump from a
dumped executable.  But this limitation already exists on Darwin (OS
X), and would not be a big practical issue.

                                     YAMAMOTO Mitsuharu
                                mituharu@math.s.chiba-u.ac.jp