From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked] Date: Mon, 25 Jun 2007 17:30:53 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <467A4F49.9040906@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1182760268 18188 80.91.229.12 (25 Jun 2007 08:31:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 25 Jun 2007 08:31:08 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 25 10:31:05 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1I2jyS-0003Ow-2R for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2007 10:31:04 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2jyR-0001JV-9t for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2007 04:31:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I2jyN-0001JQ-SC for emacs-devel@gnu.org; Mon, 25 Jun 2007 04:30:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I2jyM-0001JE-7L for emacs-devel@gnu.org; Mon, 25 Jun 2007 04:30:59 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2jyM-0001JA-3O for emacs-devel@gnu.org; Mon, 25 Jun 2007 04:30:58 -0400 Original-Received: from ntp.math.s.chiba-u.ac.jp ([133.82.132.2] helo=mathmail.math.s.chiba-u.ac.jp) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I2jyL-0006AJ-Ew for emacs-devel@gnu.org; Mon, 25 Jun 2007 04:30:57 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 567962C40; Mon, 25 Jun 2007 17:30:53 +0900 (JST) In-Reply-To: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.1.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-kernel: NetBSD 3.0 (DF) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:73794 Archived-At: >>>>> On Mon, 25 Jun 2007 01:33:59 -0400, Ken Raeburn said: >> ! /* Copy the value of __malloc_hook to an automatic variable in >> case >> ! __malloc_hook is modified in another thread between its >> ! NULL-check and the use. */ >> ! hook = __malloc_hook; >> ! return (hook != NULL ? *hook : _malloc_internal) (size); >> } >> >> Assignment is not guaranteed to be atomic. It probably is on 32- >> bit systems, but you should not assume it. > Nor is this change guaranteed to cause there to be only one access to > "__malloc_hook", unless you change it to be declared volatile. (And, > in fact, if you're optimizing, I would've expected it to be only one > access in the original code on nearly all platforms.) As a matter of fact, the original code caused a real problem: http://lists.gnu.org/archive/html/bug-gnu-emacs/2007-06/msg00170.html > Mutex protection around accesses to the hook variable would be the > safest (and wouldn't require temporary variables or volatile > qualifiers), though performance would not be as good. Temporary variables will be necessary so that we can unlock the mutex before the actual call to the hook. We also need to add some special functions to change the hook variables and use them instead of assignments to the hook variables in alloc.c. That's why I said that "malloc in glibc 2.5 also does the same thing and I suspect that we cannot do better as long as we try to keep the same interface with respect to __malloc_hook etc." in http://lists.gnu.org/archive/html/emacs-devel/2007-06/msg01503.html YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp