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

Previous Next

Full log

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: peterhull90 <at> gmail.com, 18222 <at> debbugs.gnu.org, 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: Mon, 25 Aug 2014 12:22:20 -0400

On 8/25/2014 10:51 AM, Eli Zaretskii wrote:
>> Date: Mon, 25 Aug 2014 08:17:49 -0400
>> From: Ken Brown <kbrown <at> cornell.edu>
>> CC: peterhull90 <at> gmail.com, 18222 <at> debbugs.gnu.org
>>
>> On 8/24/2014 10:39 PM, Eli Zaretskii wrote:
>>> The problem is how to write the DUMPED and ALLOCATED_BEFORE_DUMPING
>>> macros.  For Cygwin, they use some intimate knowledge about Cygwin
>>> runtime internals; the question is, do other platforms have similar
>>> facilities and features.
>>
>> The macros on Cygwin don't use any knowledge about Cygwin runtime
>> internals.  They use knowledge about how gmalloc and unexec work on
>> Cygwin.
>
> Sorry, I meant the knowledge about the internals of sbrk used before
> dumping.

But I wonder if other platforms can do something similar.  For DUMPED, 
all they have to do is use a variable (like Cygwin's 
bss_sbrk_did_unexec) that's set to 1 right before dumping and then reset 
to 0.  For ALLOCATED_BEFORE_DUMPING, maybe there's a way to find out the 
top of the heap at the time of dumping and somehow reinitialize the 
system malloc at startup to make sure that it only uses later addresses 
after that?  Or the suggestion of Yamamoto might work.

Ken

Previous Next

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