[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ken Brown
Subject: bug#18222: 24.3.92; fork handlers in gmalloc.c can lead to deadlock
Date: Sat, 23 Aug 2014 12:00:08 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

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.


Attachment: malloc.patch
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]