[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: Mon, 25 Aug 2014 12:22:20 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 8/25/2014 10:51 AM, Eli Zaretskii wrote:
Date: Mon, 25 Aug 2014 08:17:49 -0400
From: Ken Brown <address@hidden>
CC: address@hidden, address@hidden

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

Sorry, I meant the knowledge about the internals of sbrk used before

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.


reply via email to

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