From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
To: Ken Brown <kbrown@cornell.edu>
Cc: Peter Hull <peterhull90@gmail.com>, 18222@debbugs.gnu.org
Subject: bug#18222: 24.3.92; fork handlers in gmalloc.c can lead to deadlock
Date: Mon, 25 Aug 2014 08:28:59 +0900 [thread overview]
Message-ID: <wlvbphxy9w.wl%mituharu@math.s.chiba-u.ac.jp> (raw)
In-Reply-To: <53F8BA88.4030904@cornell.edu>
>>>>> On Sat, 23 Aug 2014 12:00:08 -0400, Ken Brown <kbrown@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@math.s.chiba-u.ac.jp
next prev parent reply other threads:[~2014-08-24 23:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-08 13:09 bug#18222: 24.3.92; fork handlers in gmalloc.c can lead to deadlock Ken Brown
2014-08-09 7:44 ` YAMAMOTO Mitsuharu
2014-08-09 19:24 ` Ken Brown
2014-08-11 2:16 ` Ken Brown
2014-08-11 14:44 ` Stefan Monnier
2014-08-11 15:29 ` Ken Brown
2014-08-23 16:00 ` Ken Brown
2014-08-24 23:28 ` YAMAMOTO Mitsuharu [this message]
2014-08-25 2:39 ` Eli Zaretskii
2014-08-25 4:15 ` YAMAMOTO Mitsuharu
2014-08-25 12:17 ` Ken Brown
2014-08-25 14:51 ` Eli Zaretskii
2014-08-25 16:22 ` Ken Brown
2014-08-28 14:51 ` Ken Brown
2014-08-28 19:34 ` Glenn Morris
2014-08-28 19:40 ` Ken Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=wlvbphxy9w.wl%mituharu@math.s.chiba-u.ac.jp \
--to=mituharu@math.s.chiba-u.ac.jp \
--cc=18222@debbugs.gnu.org \
--cc=kbrown@cornell.edu \
--cc=peterhull90@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.