GNU bug report logs - #18222
24.3.92; fork handlers in gmalloc.c can lead to deadlock

Previous Next

Full log

Message #23 received at 18222 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Peter Hull <peterhull90 <at> gmail.com>, 18222 <at> debbugs.gnu.org,
 YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Subject: Re: bug#18222: 24.3.92;
 fork handlers in gmalloc.c can lead to deadlock
Date: Sat, 23 Aug 2014 12:00:08 -0400

[Message part 1 (text/plain, inline)]

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.

Ken

[malloc.patch (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.