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: Sun, 10 Aug 2014 22:16:39 -0400 Message-ID: <53E82787.7030505@cornell.edu> References: <53E4CC0B.2060200@cornell.edu> <53E67553.9090102@cornell.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1407723443 3893 80.91.229.3 (11 Aug 2014 02:17:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Aug 2014 02:17:23 +0000 (UTC) Cc: Peter Hull , 18222@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Aug 11 04:17:18 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 1XGfAj-0001Bm-Ic for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Aug 2014 04:17:17 +0200 Original-Received: from localhost ([::1]:33349 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGfAh-0001xe-0S for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Aug 2014 22:17:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43375) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGfAZ-0001xH-Qn for bug-gnu-emacs@gnu.org; Sun, 10 Aug 2014 22:17:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XGfAU-0006PZ-VT for bug-gnu-emacs@gnu.org; Sun, 10 Aug 2014 22:17:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59478) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGfAU-0006PV-R9 for bug-gnu-emacs@gnu.org; Sun, 10 Aug 2014 22:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XGfAU-0000Ba-AA for bug-gnu-emacs@gnu.org; Sun, 10 Aug 2014 22:17: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: Mon, 11 Aug 2014 02:17: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.1407723420703 (code B ref 18222); Mon, 11 Aug 2014 02:17:02 +0000 Original-Received: (at 18222) by debbugs.gnu.org; 11 Aug 2014 02:17:00 +0000 Original-Received: from localhost ([127.0.0.1]:38188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XGfAQ-0000BF-Rq for submit@debbugs.gnu.org; Sun, 10 Aug 2014 22:16:59 -0400 Original-Received: from limerock01.mail.cornell.edu ([128.84.13.241]:36297) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XGfAN-0000Ax-Lv for 18222@debbugs.gnu.org; Sun, 10 Aug 2014 22:16:56 -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 limerock01.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id s7B2Gnrn022513; Sun, 10 Aug 2014 22:16:49 -0400 Original-Received: from [172.160.100.103] (50-192-26-106-static.hfc.comcastbusiness.net [50.192.26.106]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id s7B2GlZu009702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 10 Aug 2014 22:16:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: <53E67553.9090102@cornell.edu> 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:92405 Archived-At: 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 >>>>>>> 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)