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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18222 in the body.
You can then email your comments to 18222 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Ken Brown <kbrown <at> cornell.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.92; fork handlers in gmalloc.c can lead to deadlock
Date: Fri, 08 Aug 2014 09:09:31 -0400

malloc_enable_thread() in gmalloc.c calls pthread_atfork to set up fork 
handlers.  There are a couple of problems with this, but the immediate 
reason for this bug report is a problem on Cygwin that was reported in 
the thread starting at

  https://cygwin.com/ml/cygwin/2014-07/msg00387.html

and continuing at

  https://cygwin.com/ml/cygwin/2014-08/msg00001.html.

The issue is that the 'prepare' fork handler locks the pthread_mutexes 
prior to forking, and the ensuing processing of the fork command by the 
Cygwin DLL leads to a call to malloc in the same thread, resulting in 
deadlock.  This is a long-standing problem, but it was masked until 
recently by the fact that pthread_mutexes on Cygwin were ERRORCHECK 
mutexes by default.  As of Cygwin 1.7.31, pthread_mutexes are now NORMAL 
mutexes by default, so the problem has shown up.

A simple short-term workaround would be to explicitly set the mutexes to 
be ERRORCHECK or RECURSIVE mutexes on Cygwin, thereby restoring the 
previous behavior.  But this does not seem like the right long-term 
solution, for the reasons explained here:

  https://cygwin.com/ml/cygwin/2014-08/msg00161.html
  https://cygwin.com/ml/cygwin/2014-08/msg00175.html

I know nothing about this other than what I learned from the two 
messages above, so I would appreciate some guidance.

Ken

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

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 18222 <at> debbugs.gnu.org
Subject: Re: bug#18222: 24.3.92;
 fork handlers in gmalloc.c can lead to deadlock
Date: Sat, 09 Aug 2014 16:44:50 +0900

>>>>> On Fri, 08 Aug 2014 09:09:31 -0400, Ken Brown <kbrown <at> cornell.edu> said:

> malloc_enable_thread() in gmalloc.c calls pthread_atfork to set up fork 
> handlers.  There are a couple of problems with this, but the immediate 
> reason for this bug report is a problem on Cygwin that was reported in 
> the thread starting at

>    https://cygwin.com/ml/cygwin/2014-07/msg00387.html

> and continuing at

>    https://cygwin.com/ml/cygwin/2014-08/msg00001.html.

> The issue is that the 'prepare' fork handler locks the pthread_mutexes 
> prior to forking, and the ensuing processing of the fork command by the 
> Cygwin DLL leads to a call to malloc in the same thread, resulting in 
> deadlock.  This is a long-standing problem, but it was masked until 
> recently by the fact that pthread_mutexes on Cygwin were ERRORCHECK 
> mutexes by default.  As of Cygwin 1.7.31, pthread_mutexes are now NORMAL 
> mutexes by default, so the problem has shown up.

> A simple short-term workaround would be to explicitly set the mutexes to 
> be ERRORCHECK or RECURSIVE mutexes on Cygwin, thereby restoring the 
> previous behavior.  But this does not seem like the right long-term 
> solution, for the reasons explained here:

>    https://cygwin.com/ml/cygwin/2014-08/msg00161.html
>    https://cygwin.com/ml/cygwin/2014-08/msg00175.html

> I know nothing about this other than what I learned from the two 
> messages above, so I would appreciate some guidance.

Originally, gmalloc.c bundled with Emacs was not thread-safe, so I
added some mutex code as a short-term solution:

  http://lists.gnu.org/archive/html/emacs-devel/2007-06/msg01782.html

Thread-safe malloc was required mainly for GLib (via GTK+, for
example), and atfork handers were necessary because the threads
internally used by GLib were not under our control.

All the platforms I'm currently working at use their system malloc
rather than Emacs's gmalloc.c, so I don't think I can be of much help
about this issue.  If changing mutex attributes works well, then I
think that would be good enough for a workaround for upcoming 24.4
release.  For a long term solution, it might be better to think about
a transition to Cygwin's malloc (you mentioned
malloc_set_state/malloc_get_state in (*), but they are used only when
DOUG_LEA_MALLOC is defined).

*: https://cygwin.com/ml/cygwin/2014-08/msg00167.html

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

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

From: Ken Brown <kbrown <at> cornell.edu>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: Peter Hull <peterhull90 <at> gmail.com>, 18222 <at> debbugs.gnu.org
Subject: Re: bug#18222: 24.3.92;
 fork handlers in gmalloc.c can lead to deadlock
Date: Sat, 09 Aug 2014 15:24:03 -0400

On 8/9/2014 3:44 AM, YAMAMOTO Mitsuharu wrote:
>>>>>> On Fri, 08 Aug 2014 09:09:31 -0400, Ken Brown <kbrown <at> cornell.edu> said:
>
>> malloc_enable_thread() in gmalloc.c calls pthread_atfork to set up fork
>> handlers.  There are a couple of problems with this, but the immediate
>> reason for this bug report is a problem on Cygwin that was reported in
>> the thread starting at
>
>>     https://cygwin.com/ml/cygwin/2014-07/msg00387.html
>
>> and continuing at
>
>>     https://cygwin.com/ml/cygwin/2014-08/msg00001.html.
>
>> The issue is that the 'prepare' fork handler locks the pthread_mutexes
>> prior to forking, and the ensuing processing of the fork command by the
>> Cygwin DLL leads to a call to malloc in the same thread, resulting in
>> deadlock.  This is a long-standing problem, but it was masked until
>> recently by the fact that pthread_mutexes on Cygwin were ERRORCHECK
>> mutexes by default.  As of Cygwin 1.7.31, pthread_mutexes are now NORMAL
>> mutexes by default, so the problem has shown up.
>
>> A simple short-term workaround would be to explicitly set the mutexes to
>> be ERRORCHECK or RECURSIVE mutexes on Cygwin, thereby restoring the
>> previous behavior.  But this does not seem like the right long-term
>> solution, for the reasons explained here:
>
>>     https://cygwin.com/ml/cygwin/2014-08/msg00161.html
>>     https://cygwin.com/ml/cygwin/2014-08/msg00175.html
>
>> I know nothing about this other than what I learned from the two
>> messages above, so I would appreciate some guidance.
>
> Originally, gmalloc.c bundled with Emacs was not thread-safe, so I
> added some mutex code as a short-term solution:
>
>    http://lists.gnu.org/archive/html/emacs-devel/2007-06/msg01782.html
>
> Thread-safe malloc was required mainly for GLib (via GTK+, for
> example), and atfork handers were necessary because the threads
> internally used by GLib were not under our control.
>
> All the platforms I'm currently working at use their system malloc
> rather than Emacs's gmalloc.c, so I don't think I can be of much help
> about this issue.  If changing mutex attributes works well, then I
> think that would be good enough for a workaround for upcoming 24.4
> release.

OK.  For maximum safety, I should probably set the type of the mutexes 
to ERRORCHECK, as they were in Cygwin 1.7.30, even though I think 
RECURSIVE would work just as well.

> For a long term solution, it might be better to think about
> a transition to Cygwin's malloc

I'll try to do this, but it's not at all clear how, given the way emacs 
is built on Cygwin.  (See the comments at lines 309 and 1301 in gmalloc.c.)

> (you mentioned
> malloc_set_state/malloc_get_state in (*), but they are used only when
> DOUG_LEA_MALLOC is defined).

You're right, although there's something of a Catch 22 here.  Cygwin's 
malloc is in fact Doug Lea malloc, but the emacs configure test for 
DOUG_LEA_MALLOC simply tests for malloc_set_state and malloc_get_state 
(and a couple of hooks).

In any case, I think it would be much easier to switch to Cygwin's 
malloc if it had malloc_set_state and malloc_get_state.  I wonder how 
hard it would be to add those.

Ken

Message #14 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: Sun, 10 Aug 2014 22:16:39 -0400

On 8/9/2014 3:24 PM, Ken Brown wrote:
> On 8/9/2014 3:44 AM, YAMAMOTO Mitsuharu wrote:
>>>>>>> On Fri, 08 Aug 2014 09:09:31 -0400, Ken Brown 
>>>>>>> <kbrown <at> cornell.edu> said:
>>
>>> malloc_enable_thread() in gmalloc.c calls pthread_atfork to set up fork
>>> handlers.  There are a couple of problems with this, but the immediate
>>> reason for this bug report is a problem on Cygwin that was reported in
>>> the thread starting at
>>
>>>     https://cygwin.com/ml/cygwin/2014-07/msg00387.html
>>
>>> and continuing at
>>
>>>     https://cygwin.com/ml/cygwin/2014-08/msg00001.html.
>>
>>> The issue is that the 'prepare' fork handler locks the pthread_mutexes
>>> prior to forking, and the ensuing processing of the fork command by the
>>> Cygwin DLL leads to a call to malloc in the same thread, resulting in
>>> deadlock.  This is a long-standing problem, but it was masked until
>>> recently by the fact that pthread_mutexes on Cygwin were ERRORCHECK
>>> mutexes by default.  As of Cygwin 1.7.31, pthread_mutexes are now NORMAL
>>> mutexes by default, so the problem has shown up.
>>
>>> A simple short-term workaround would be to explicitly set the mutexes to
>>> be ERRORCHECK or RECURSIVE mutexes on Cygwin, thereby restoring the
>>> previous behavior.  But this does not seem like the right long-term
>>> solution, for the reasons explained here:
>>
>>>     https://cygwin.com/ml/cygwin/2014-08/msg00161.html
>>>     https://cygwin.com/ml/cygwin/2014-08/msg00175.html
>>
>>> I know nothing about this other than what I learned from the two
>>> messages above, so I would appreciate some guidance.
>>
>> Originally, gmalloc.c bundled with Emacs was not thread-safe, so I
>> added some mutex code as a short-term solution:
>>
>>    http://lists.gnu.org/archive/html/emacs-devel/2007-06/msg01782.html
>>
>> Thread-safe malloc was required mainly for GLib (via GTK+, for
>> example), and atfork handers were necessary because the threads
>> internally used by GLib were not under our control.
>>
>> All the platforms I'm currently working at use their system malloc
>> rather than Emacs's gmalloc.c, so I don't think I can be of much help
>> about this issue.  If changing mutex attributes works well, then I
>> think that would be good enough for a workaround for upcoming 24.4
>> release.
> 
> OK.  For maximum safety, I should probably set the type of the mutexes 
> to ERRORCHECK, as they were in Cygwin 1.7.30, even though I think 
> RECURSIVE would work just as well.

The patch below does this.  Stefan, is it OK to install this in the emacs-24 branch?

Ken

=== modified file 'src/gmalloc.c'
--- src/gmalloc.c       2014-03-04 19:02:49 +0000
+++ src/gmalloc.c       2014-08-10 13:24:52 +0000
@@ -490,8 +490,18 @@
 }

 #ifdef USE_PTHREAD
+/* On Cygwin prior to 1.7.31, pthread_mutexes were ERRORCHECK mutexes
+   by default.  When the default changed to NORMAL in Cygwin-1.7.31,
+   deadlocks occurred (bug#18222).  As a temporary workaround, we
+   explicitly set the mutexes to be of ERRORCHECK type, restoring the
+   previous behavior.  */
+#ifdef CYGWIN
+pthread_mutex_t _malloc_mutex = PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP;
+pthread_mutex_t _aligned_blocks_mutex = PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP;
+#else  /* not CYGWIN */
 pthread_mutex_t _malloc_mutex = PTHREAD_MUTEX_INITIALIZER;
 pthread_mutex_t _aligned_blocks_mutex = PTHREAD_MUTEX_INITIALIZER;
+#endif /* not CYGWIN */
 int _malloc_thread_enabled_p;

 static void
@@ -526,14 +536,23 @@
      initialized mutexes when they are used first.  To avoid such a
      situation, we initialize mutexes here while their use is
      disabled in malloc etc.  */
+#ifdef CYGWIN
+  /* Use ERRORCHECK mutexes; see comment above. */
+  pthread_mutexattr_t attr;
+  pthread_mutexattr_init (&attr);
+  pthread_mutexattr_settype (&attr, PTHREAD_MUTEX_ERRORCHECK);
+  pthread_mutex_init (&_malloc_mutex, &attr);
+  pthread_mutex_init (&_aligned_blocks_mutex, &attr);
+#else  /* not CYGWIN */
   pthread_mutex_init (&_malloc_mutex, NULL);
   pthread_mutex_init (&_aligned_blocks_mutex, NULL);
+#endif /* not CYGWIN */
   pthread_atfork (malloc_atfork_handler_prepare,
                  malloc_atfork_handler_parent,
                  malloc_atfork_handler_child);
   _malloc_thread_enabled_p = 1;
 }
-#endif
+#endif /* USE_PTHREAD */

 static void
 malloc_initialize_1 (void)

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ken Brown <kbrown <at> cornell.edu>
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: Mon, 11 Aug 2014 10:44:14 -0400

> The patch below does this.  Stefan, is it OK to install this in the
> emacs-24 branch?

Yes, go ahead, thanks,


        Stefan

Message #20 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: Mon, 11 Aug 2014 11:29:09 -0400

On 8/11/2014 10:44 AM, Stefan Monnier wrote:
>> The patch below does this.  Stefan, is it OK to install this in the
>> emacs-24 branch?
>
> Yes, go ahead, thanks,

Done, as bzr revno 117441.  I'm leaving the bug open, since a better fix 
is needed for the trunk.

Ken

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)]

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

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

>>>>> On Sat, 23 Aug 2014 12:00:08 -0400, Ken Brown <kbrown <at> 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 <at> math.s.chiba-u.ac.jp

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: peterhull90 <at> gmail.com, 18222 <at> debbugs.gnu.org, kbrown <at> cornell.edu
Subject: Re: bug#18222: 24.3.92;
 fork handlers in gmalloc.c can lead to deadlock
Date: Mon, 25 Aug 2014 05:39:58 +0300

> Date: Mon, 25 Aug 2014 08:28:59 +0900
> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> Cc: Peter Hull <peterhull90 <at> gmail.com>, 18222 <at> debbugs.gnu.org
> 
> I think it's worth trying also on other platforms that use gmalloc.

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.

There's also the MinGW way of getting rid of gmalloc, but it needs a
different feature: the ability to specify a user-defined sbrk
function (which MS-Windows supports).

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

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: peterhull90 <at> gmail.com, 18222 <at> debbugs.gnu.org, kbrown <at> cornell.edu
Subject: Re: bug#18222: 24.3.92;
 fork handlers in gmalloc.c can lead to deadlock
Date: Mon, 25 Aug 2014 13:15:21 +0900

>>>>> On Mon, 25 Aug 2014 05:39:58 +0300, Eli Zaretskii <eliz <at> gnu.org> said:

>> Date: Mon, 25 Aug 2014 08:28:59 +0900 From: YAMAMOTO Mitsuharu
>> <mituharu <at> math.s.chiba-u.ac.jp> Cc: Peter Hull
>> <peterhull90 <at> gmail.com>, 18222 <at> debbugs.gnu.org
>> 
>> I think it's worth trying also on other platforms that use gmalloc.

> 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.

If the system malloc always returns a 16-byte aligned address (I'm not
sure if that is the case for *BSDs), and if we actually only need
8-byte alignment for memory allocated before dumping, then we can
determine whether the address has been allocated before dumping or not
by tweaking the address returned by malloc before dumping so it always
returns a value p such that (p & 8) == 8.  Actually this is how
unexec_malloc etc. in unexmacosx.c work.

				     YAMAMOTO Mitsuharu
				mituharu <at> math.s.chiba-u.ac.jp

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>,
 YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: peterhull90 <at> gmail.com, 18222 <at> debbugs.gnu.org
Subject: Re: bug#18222: 24.3.92;
 fork handlers in gmalloc.c can lead to deadlock
Date: Mon, 25 Aug 2014 08:17:49 -0400

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.  Prior to dumping, gmalloc uses a version of sbrk defined in 
sheap.c, which allocates space in the static heap (also defined in 
sheap.c).  But the question still remains about what to do on other 
platforms.

Ken

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
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 17:51:02 +0300

> 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.

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

Message #44 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
Subject: Re: bug#18222: 24.3.92;
 fork handlers in gmalloc.c can lead to deadlock
Date: Thu, 28 Aug 2014 10:51:29 -0400

I've installed my patch (with minor modifications) into the trunk as bzr 
revision 117758.  I'll leave the bug open for a while longer in case the 
*BSD people want to discuss it.

Ken

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

From: Glenn Morris <rgm <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 18222 <at> debbugs.gnu.org, peterhull90 <at> gmail.com
Subject: Re: bug#18222: 24.3.92;
 fork handlers in gmalloc.c can lead to deadlock
Date: Thu, 28 Aug 2014 15:34:55 -0400

Ken Brown wrote:

> I've installed my patch (with minor modifications) into the trunk as
> bzr revision 117758.  I'll leave the bug open for a while longer in
> case the *BSD people want to discuss it.

Closing a bug doesn't prevent further discussion.
(In my experience not closing it just means people tend to forget to do
that later.)

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 18222-done <at> debbugs.gnu.org,
 peterhull90 <at> gmail.com
Subject: Re: bug#18222: 24.3.92;
 fork handlers in gmalloc.c can lead to deadlock
Date: Thu, 28 Aug 2014 15:40:18 -0400

Version: 24.5

> Closing a bug doesn't prevent further discussion.
> (In my experience not closing it just means people tend to forget to do
> that later.)

OK. Closed.

Previous Next

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