From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Brown Newsgroups: gmane.emacs.bugs Subject: bug#18222: 24.3.92; fork handlers in gmalloc.c can lead to deadlock Date: Sat, 09 Aug 2014 15:24:03 -0400 Message-ID: <53E67553.9090102@cornell.edu> References: <53E4CC0B.2060200@cornell.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1407612322 16812 80.91.229.3 (9 Aug 2014 19:25:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Aug 2014 19:25:22 +0000 (UTC) Cc: Peter Hull , 18222@debbugs.gnu.org To: YAMAMOTO Mitsuharu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 09 21:25:16 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XGCGR-0008RE-QM for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Aug 2014 21:25:16 +0200 Original-Received: from localhost ([::1]:57194 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGCGR-0001PB-9j for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Aug 2014 15:25:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGCGK-0001Mq-7e for bug-gnu-emacs@gnu.org; Sat, 09 Aug 2014 15:25:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XGCGF-0008T5-CR for bug-gnu-emacs@gnu.org; Sat, 09 Aug 2014 15:25:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57990) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGCGF-0008So-9T for bug-gnu-emacs@gnu.org; Sat, 09 Aug 2014 15:25:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XGCGE-0001L8-CY for bug-gnu-emacs@gnu.org; Sat, 09 Aug 2014 15:25:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ken Brown Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Aug 2014 19:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18222 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18222-submit@debbugs.gnu.org id=B18222.14076122645084 (code B ref 18222); Sat, 09 Aug 2014 19:25:02 +0000 Original-Received: (at 18222) by debbugs.gnu.org; 9 Aug 2014 19:24:24 +0000 Original-Received: from localhost ([127.0.0.1]:36700 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XGCFc-0001Jw-7I for submit@debbugs.gnu.org; Sat, 09 Aug 2014 15:24:24 -0400 Original-Received: from limerock02.mail.cornell.edu ([128.84.13.242]:40832) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XGCFZ-0001Jj-Qa for 18222@debbugs.gnu.org; Sat, 09 Aug 2014 15:24:22 -0400 X-CornellRouted: This message has been Routed already. Original-Received: from authusersmtp.mail.cornell.edu (granite3.serverfarm.cornell.edu [10.16.197.8]) by limerock02.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id s79JOFAu005321; Sat, 9 Aug 2014 15:24:16 -0400 Original-Received: from [172.18.83.189] ([70.158.101.109]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id s79JOB59011401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 9 Aug 2014 15:24:13 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:92345 Archived-At: On 8/9/2014 3:44 AM, YAMAMOTO Mitsuharu wrote: >>>>>> On Fri, 08 Aug 2014 09:09:31 -0400, Ken Brown 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