unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
@ 2007-06-17 21:49 Richard Stallman
  2007-06-18  1:11 ` YAMAMOTO Mitsuharu
  0 siblings, 1 reply; 23+ messages in thread
From: Richard Stallman @ 2007-06-17 21:49 UTC (permalink / raw)
  To: emacs-devel

Would someone else (other that Mitsuharu) please study this
patch to check whether it is really correct?  Things like this
can be tricky.

------- Start of forwarded message -------
X-Spam-Status: No, score=0.5 required=5.0 tests=DNS_FROM_RFC_ABUSE,
	UNPARSEABLE_RELAY autolearn=no version=3.1.0
Date: Thu, 14 Jun 2007 11:16:30 +0900
From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
To: Gary Mills <mills@cc.umanitoba.ca>
In-Reply-To: <20070610141003.GA12085@cc.umanitoba.ca>
Organization: Faculty of Science, Chiba University
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Cc: bug-gnu-emacs@gnu.org
Subject: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked

I found a possible problem, which may or may not be relevant to this
issue, in the initialization of the recursive mutex in src/gmalloc.c.
Could you try this patch?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: src/gmalloc.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/gmalloc.c,v
retrieving revision 1.21
diff -c -p -r1.21 gmalloc.c
*** src/gmalloc.c	28 Mar 2007 08:16:05 -0000	1.21
- --- src/gmalloc.c	14 Jun 2007 02:03:33 -0000
*************** extern __malloc_size_t _bytes_free;
*** 235,240 ****
- --- 235,243 ----
  extern __ptr_t _malloc_internal PP ((__malloc_size_t __size));
  extern __ptr_t _realloc_internal PP ((__ptr_t __ptr, __malloc_size_t __size));
  extern void _free_internal PP ((__ptr_t __ptr));
+ extern __ptr_t _malloc_internal_nolock PP ((__malloc_size_t __size));
+ extern __ptr_t _realloc_internal_nolock PP ((__ptr_t __ptr, __malloc_size_t __size));
+ extern void _free_internal_nolock PP ((__ptr_t __ptr));
  
  #ifdef USE_PTHREAD
  extern pthread_mutex_t _malloc_mutex;
*************** register_heapinfo ()
*** 554,560 ****
  
  #ifdef USE_PTHREAD
  static pthread_once_t malloc_init_once_control = PTHREAD_ONCE_INIT;
! pthread_mutex_t _malloc_mutex;
  #endif
  
  static void
- --- 557,563 ----
  
  #ifdef USE_PTHREAD
  static pthread_once_t malloc_init_once_control = PTHREAD_ONCE_INIT;
! pthread_mutex_t _malloc_mutex = PTHREAD_MUTEX_INITIALIZER;
  #endif
  
  static void
*************** malloc_initialize_1 ()
*** 567,573 ****
    if (__malloc_initialize_hook)
      (*__malloc_initialize_hook) ();
  
! #ifdef USE_PTHREAD
    {
      pthread_mutexattr_t attr;
  
- --- 570,578 ----
    if (__malloc_initialize_hook)
      (*__malloc_initialize_hook) ();
  
!   /* We don't use recursive mutex because pthread_mutexattr_init may
!      call malloc internally.  */
! #if 0 /* defined (USE_PTHREAD) */
    {
      pthread_mutexattr_t attr;
  
*************** morecore (size)
*** 661,667 ****
  	     `morecore_recursing' flag and return null.  */
  	  int save = errno;	/* Don't want to clobber errno with ENOMEM.  */
  	  morecore_recursing = 1;
! 	  newinfo = (malloc_info *) _realloc_internal
  	    (_heapinfo, newsize * sizeof (malloc_info));
  	  morecore_recursing = 0;
  	  if (newinfo == NULL)
- --- 666,672 ----
  	     `morecore_recursing' flag and return null.  */
  	  int save = errno;	/* Don't want to clobber errno with ENOMEM.  */
  	  morecore_recursing = 1;
! 	  newinfo = (malloc_info *) _realloc_internal_nolock
  	    (_heapinfo, newsize * sizeof (malloc_info));
  	  morecore_recursing = 0;
  	  if (newinfo == NULL)
*************** morecore (size)
*** 717,723 ****
        /* Reset _heaplimit so _free_internal never decides
  	 it can relocate or resize the info table.  */
        _heaplimit = 0;
!       _free_internal (oldinfo);
        PROTECT_MALLOC_STATE (0);
  
        /* The new heap limit includes the new table just allocated.  */
- --- 722,728 ----
        /* Reset _heaplimit so _free_internal never decides
  	 it can relocate or resize the info table.  */
        _heaplimit = 0;
!       _free_internal_nolock (oldinfo);
        PROTECT_MALLOC_STATE (0);
  
        /* The new heap limit includes the new table just allocated.  */
*************** morecore (size)
*** 732,738 ****
  
  /* Allocate memory from the heap.  */
  __ptr_t
! _malloc_internal (size)
       __malloc_size_t size;
  {
    __ptr_t result;
- --- 737,743 ----
  
  /* Allocate memory from the heap.  */
  __ptr_t
! _malloc_internal_nolock (size)
       __malloc_size_t size;
  {
    __ptr_t result;
*************** _malloc_internal (size)
*** 752,758 ****
      return NULL;
  #endif
  
- -   LOCK ();
    PROTECT_MALLOC_STATE (0);
  
    if (size < sizeof (struct list))
- --- 757,762 ----
*************** _malloc_internal (size)
*** 802,811 ****
  	  /* No free fragments of the desired size, so get a new block
  	     and break it into fragments, returning the first.  */
  #ifdef GC_MALLOC_CHECK
! 	  result = _malloc_internal (BLOCKSIZE);
  	  PROTECT_MALLOC_STATE (0);
  #else
! 	  result = malloc (BLOCKSIZE);
  #endif
  	  if (result == NULL)
  	    {
- --- 806,815 ----
  	  /* No free fragments of the desired size, so get a new block
  	     and break it into fragments, returning the first.  */
  #ifdef GC_MALLOC_CHECK
! 	  result = _malloc_internal_nolock (BLOCKSIZE);
  	  PROTECT_MALLOC_STATE (0);
  #else
! 	  result = _malloc_internal_nolock (BLOCKSIZE);
  #endif
  	  if (result == NULL)
  	    {
*************** _malloc_internal (size)
*** 932,938 ****
- --- 936,954 ----
  
    PROTECT_MALLOC_STATE (1);
   out:
+   return result;
+ }
+ 
+ __ptr_t
+ _malloc_internal (size)
+      __malloc_size_t size;
+ {
+   __ptr_t result;
+ 
+   LOCK ();
+   result = _malloc_internal_nolock (size);
    UNLOCK ();
+ 
    return result;
  }
  
*************** void (*__free_hook) PP ((__ptr_t __ptr))
*** 1024,1032 ****
  struct alignlist *_aligned_blocks = NULL;
  
  /* Return memory to the heap.
!    Like `free' but don't call a __free_hook if there is one.  */
  void
! _free_internal (ptr)
       __ptr_t ptr;
  {
    int type;
- --- 1040,1048 ----
  struct alignlist *_aligned_blocks = NULL;
  
  /* Return memory to the heap.
!    Like `_free_internal' but don't lock mutex.  */
  void
! _free_internal_nolock (ptr)
       __ptr_t ptr;
  {
    int type;
*************** _free_internal (ptr)
*** 1043,1049 ****
    if (ptr == NULL)
      return;
  
- -   LOCK ();
    PROTECT_MALLOC_STATE (0);
  
    for (l = _aligned_blocks; l != NULL; l = l->next)
- --- 1059,1064 ----
*************** _free_internal (ptr)
*** 1158,1164 ****
  		 table's blocks to the system before we have copied them to
  		 the new location.  */
  	      _heaplimit = 0;
! 	      _free_internal (_heapinfo);
  	      _heaplimit = oldlimit;
  
  	      /* Tell malloc to search from the beginning of the heap for
- --- 1173,1179 ----
  		 table's blocks to the system before we have copied them to
  		 the new location.  */
  	      _heaplimit = 0;
! 	      _free_internal_nolock (_heapinfo);
  	      _heaplimit = oldlimit;
  
  	      /* Tell malloc to search from the beginning of the heap for
*************** _free_internal (ptr)
*** 1166,1173 ****
  	      _heapindex = 0;
  
  	      /* Allocate new space for the info table and move its data.  */
! 	      newinfo = (malloc_info *) _malloc_internal (info_blocks
! 							  * BLOCKSIZE);
  	      PROTECT_MALLOC_STATE (0);
  	      memmove (newinfo, _heapinfo, info_blocks * BLOCKSIZE);
  	      _heapinfo = newinfo;
- --- 1181,1188 ----
  	      _heapindex = 0;
  
  	      /* Allocate new space for the info table and move its data.  */
! 	      newinfo = (malloc_info *) _malloc_internal_nolock (info_blocks
! 								 * BLOCKSIZE);
  	      PROTECT_MALLOC_STATE (0);
  	      memmove (newinfo, _heapinfo, info_blocks * BLOCKSIZE);
  	      _heapinfo = newinfo;
*************** _free_internal (ptr)
*** 1231,1239 ****
  	  _bytes_free -= BLOCKSIZE;
  
  #ifdef GC_MALLOC_CHECK
! 	  _free_internal (ADDRESS (block));
  #else
! 	  free (ADDRESS (block));
  #endif
  	}
        else if (_heapinfo[block].busy.info.frag.nfree != 0)
- --- 1246,1254 ----
  	  _bytes_free -= BLOCKSIZE;
  
  #ifdef GC_MALLOC_CHECK
! 	  _free_internal_nolock (ADDRESS (block));
  #else
! 	  _free_internal_nolock (ADDRESS (block));
  #endif
  	}
        else if (_heapinfo[block].busy.info.frag.nfree != 0)
*************** _free_internal (ptr)
*** 1269,1274 ****
- --- 1284,1299 ----
      }
  
    PROTECT_MALLOC_STATE (1);
+ }
+ 
+ /* Return memory to the heap.
+    Like `free' but don't call a __free_hook if there is one.  */
+ void
+ _free_internal (ptr)
+      __ptr_t ptr;
+ {
+   LOCK ();
+   _free_internal_nolock (ptr);
    UNLOCK ();
  }
  
*************** __ptr_t (*__realloc_hook) PP ((__ptr_t _
*** 1415,1421 ****
     new region.  This module has incestuous knowledge of the
     internals of both free and malloc. */
  __ptr_t
! _realloc_internal (ptr, size)
       __ptr_t ptr;
       __malloc_size_t size;
  {
- --- 1440,1446 ----
     new region.  This module has incestuous knowledge of the
     internals of both free and malloc. */
  __ptr_t
! _realloc_internal_nolock (ptr, size)
       __ptr_t ptr;
       __malloc_size_t size;
  {
*************** _realloc_internal (ptr, size)
*** 1425,1439 ****
  
    if (size == 0)
      {
!       _free_internal (ptr);
!       return _malloc_internal (0);
      }
    else if (ptr == NULL)
!     return _malloc_internal (size);
  
    block = BLOCK (ptr);
  
- -   LOCK ();
    PROTECT_MALLOC_STATE (0);
  
    type = _heapinfo[block].busy.type;
- --- 1450,1463 ----
  
    if (size == 0)
      {
!       _free_internal_nolock (ptr);
!       return _malloc_internal_nolock (0);
      }
    else if (ptr == NULL)
!     return _malloc_internal_nolock (size);
  
    block = BLOCK (ptr);
  
    PROTECT_MALLOC_STATE (0);
  
    type = _heapinfo[block].busy.type;
*************** _realloc_internal (ptr, size)
*** 1443,1453 ****
        /* Maybe reallocate a large block to a small fragment.  */
        if (size <= BLOCKSIZE / 2)
  	{
! 	  result = _malloc_internal (size);
  	  if (result != NULL)
  	    {
  	      memcpy (result, ptr, size);
! 	      _free_internal (ptr);
  	      goto out;
  	    }
  	}
- --- 1467,1477 ----
        /* Maybe reallocate a large block to a small fragment.  */
        if (size <= BLOCKSIZE / 2)
  	{
! 	  result = _malloc_internal_nolock (size);
  	  if (result != NULL)
  	    {
  	      memcpy (result, ptr, size);
! 	      _free_internal_nolock (ptr);
  	      goto out;
  	    }
  	}
*************** _realloc_internal (ptr, size)
*** 1467,1473 ****
  	     Now we will free this chunk; increment the statistics counter
  	     so it doesn't become wrong when _free_internal decrements it.  */
  	  ++_chunks_used;
! 	  _free_internal (ADDRESS (block + blocks));
  	  result = ptr;
  	}
        else if (blocks == _heapinfo[block].busy.info.size)
- --- 1491,1497 ----
  	     Now we will free this chunk; increment the statistics counter
  	     so it doesn't become wrong when _free_internal decrements it.  */
  	  ++_chunks_used;
! 	  _free_internal_nolock (ADDRESS (block + blocks));
  	  result = ptr;
  	}
        else if (blocks == _heapinfo[block].busy.info.size)
*************** _realloc_internal (ptr, size)
*** 1482,1489 ****
  	  /* Prevent free from actually returning memory to the system.  */
  	  oldlimit = _heaplimit;
  	  _heaplimit = 0;
! 	  _free_internal (ptr);
! 	  result = _malloc_internal (size);
  	  PROTECT_MALLOC_STATE (0);
  	  if (_heaplimit == 0)
  	    _heaplimit = oldlimit;
- --- 1506,1513 ----
  	  /* Prevent free from actually returning memory to the system.  */
  	  oldlimit = _heaplimit;
  	  _heaplimit = 0;
! 	  _free_internal_nolock (ptr);
! 	  result = _malloc_internal_nolock (size);
  	  PROTECT_MALLOC_STATE (0);
  	  if (_heaplimit == 0)
  	    _heaplimit = oldlimit;
*************** _realloc_internal (ptr, size)
*** 1493,1505 ****
  		 the thing we just freed.  Unfortunately it might
  		 have been coalesced with its neighbors.  */
  	      if (_heapindex == block)
! 	        (void) _malloc_internal (blocks * BLOCKSIZE);
  	      else
  		{
  		  __ptr_t previous
! 		    = _malloc_internal ((block - _heapindex) * BLOCKSIZE);
! 		  (void) _malloc_internal (blocks * BLOCKSIZE);
! 		  _free_internal (previous);
  		}
  	      goto out;
  	    }
- --- 1517,1529 ----
  		 the thing we just freed.  Unfortunately it might
  		 have been coalesced with its neighbors.  */
  	      if (_heapindex == block)
! 	        (void) _malloc_internal_nolock (blocks * BLOCKSIZE);
  	      else
  		{
  		  __ptr_t previous
! 		    = _malloc_internal_nolock ((block - _heapindex) * BLOCKSIZE);
! 		  (void) _malloc_internal_nolock (blocks * BLOCKSIZE);
! 		  _free_internal_nolock (previous);
  		}
  	      goto out;
  	    }
*************** _realloc_internal (ptr, size)
*** 1519,1536 ****
  	{
  	  /* The new size is different; allocate a new space,
  	     and copy the lesser of the new size and the old. */
! 	  result = _malloc_internal (size);
  	  if (result == NULL)
  	    goto out;
  	  memcpy (result, ptr, min (size, (__malloc_size_t) 1 << type));
! 	  _free_internal (ptr);
  	}
        break;
      }
  
    PROTECT_MALLOC_STATE (1);
   out:
    UNLOCK ();
    return result;
  }
  
- --- 1543,1573 ----
  	{
  	  /* The new size is different; allocate a new space,
  	     and copy the lesser of the new size and the old. */
! 	  result = _malloc_internal_nolock (size);
  	  if (result == NULL)
  	    goto out;
  	  memcpy (result, ptr, min (size, (__malloc_size_t) 1 << type));
! 	  _free_internal_nolock (ptr);
  	}
        break;
      }
  
    PROTECT_MALLOC_STATE (1);
   out:
+   return result;
+ }
+ 
+ __ptr_t
+ _realloc_internal (ptr, size)
+      __ptr_t ptr;
+      __malloc_size_t size;
+ {
+   __ptr_t result;
+ 
+   LOCK();
+   result = _realloc_internal_nolock (ptr, size);
    UNLOCK ();
+ 
    return result;
  }
  


_______________________________________________
bug-gnu-emacs mailing list
bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
------- End of forwarded message -------

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-17 21:49 [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked] Richard Stallman
@ 2007-06-18  1:11 ` YAMAMOTO Mitsuharu
  2007-06-21 10:13   ` Jan Djärv
  2007-06-24 23:47   ` Richard Stallman
  0 siblings, 2 replies; 23+ messages in thread
From: YAMAMOTO Mitsuharu @ 2007-06-18  1:11 UTC (permalink / raw)
  To: rms; +Cc: emacs-devel

>>>>> On Sun, 17 Jun 2007 17:49:28 -0400, Richard Stallman <rms@gnu.org> said:

> Would someone else (other that Mitsuharu) please study this patch to
> check whether it is really correct?  Things like this can be tricky.

Please take a look at the following one instead.  It tries to fix the
following problems of gmalloc.c with HAVE_GTK_AND_PTHREAD in Emacs 22.1.

* HAVE_GTK_AND_PTHREAD was checked before including config.h.
* malloc_initialize_1 called pthread_mutexattr_init that may call malloc.
* _aligned_blocks was not protected.
* __malloc_hook etc. may be modified between its NULL-check and the use.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: src/gmalloc.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/gmalloc.c,v
retrieving revision 1.21
diff -c -p -r1.21 gmalloc.c
*** src/gmalloc.c	28 Mar 2007 08:16:05 -0000	1.21
--- src/gmalloc.c	18 Jun 2007 01:00:00 -0000
***************
*** 1,9 ****
  /* This file is no longer automatically generated from libc.  */
  
  #define _MALLOC_INTERNAL
- #ifdef HAVE_GTK_AND_PTHREAD
- #define USE_PTHREAD
- #endif
  
  /* The malloc headers and source files from the C library follow here.  */
  
--- 1,6 ----
*************** Fifth Floor, Boston, MA 02110-1301, USA.
*** 40,45 ****
--- 37,46 ----
  #include <config.h>
  #endif
  
+ #ifdef HAVE_GTK_AND_PTHREAD
+ #define USE_PTHREAD
+ #endif
+ 
  #if ((defined __cplusplus || (defined (__STDC__) && __STDC__) \
        || defined STDC_HEADERS || defined PROTOTYPES) \
       && ! defined (BROKEN_PROTOTYPES))
*************** extern __malloc_size_t _bytes_free;
*** 235,248 ****
  extern __ptr_t _malloc_internal PP ((__malloc_size_t __size));
  extern __ptr_t _realloc_internal PP ((__ptr_t __ptr, __malloc_size_t __size));
  extern void _free_internal PP ((__ptr_t __ptr));
  
  #ifdef USE_PTHREAD
! extern pthread_mutex_t _malloc_mutex;
  #define LOCK()     pthread_mutex_lock (&_malloc_mutex)
  #define UNLOCK()   pthread_mutex_unlock (&_malloc_mutex)
  #else
  #define LOCK()
  #define UNLOCK()
  #endif
  
  #endif /* _MALLOC_INTERNAL.  */
--- 236,256 ----
  extern __ptr_t _malloc_internal PP ((__malloc_size_t __size));
  extern __ptr_t _realloc_internal PP ((__ptr_t __ptr, __malloc_size_t __size));
  extern void _free_internal PP ((__ptr_t __ptr));
+ extern __ptr_t _malloc_internal_nolock PP ((__malloc_size_t __size));
+ extern __ptr_t _realloc_internal_nolock PP ((__ptr_t __ptr, __malloc_size_t __size));
+ extern void _free_internal_nolock PP ((__ptr_t __ptr));
  
  #ifdef USE_PTHREAD
! extern pthread_mutex_t _malloc_mutex, _aligned_blocks_mutex;
  #define LOCK()     pthread_mutex_lock (&_malloc_mutex)
  #define UNLOCK()   pthread_mutex_unlock (&_malloc_mutex)
+ #define LOCK_ALIGNED_BLOCKS()     pthread_mutex_lock (&_aligned_blocks_mutex)
+ #define UNLOCK_ALIGNED_BLOCKS()   pthread_mutex_unlock (&_aligned_blocks_mutex)
  #else
  #define LOCK()
  #define UNLOCK()
+ #define LOCK_ALIGNED_BLOCKS()
+ #define UNLOCK_ALIGNED_BLOCKS()
  #endif
  
  #endif /* _MALLOC_INTERNAL.  */
*************** register_heapinfo ()
*** 554,560 ****
  
  #ifdef USE_PTHREAD
  static pthread_once_t malloc_init_once_control = PTHREAD_ONCE_INIT;
! pthread_mutex_t _malloc_mutex;
  #endif
  
  static void
--- 562,569 ----
  
  #ifdef USE_PTHREAD
  static pthread_once_t malloc_init_once_control = PTHREAD_ONCE_INIT;
! pthread_mutex_t _malloc_mutex = PTHREAD_MUTEX_INITIALIZER;
! pthread_mutex_t _aligned_blocks_mutex = PTHREAD_MUTEX_INITIALIZER;
  #endif
  
  static void
*************** malloc_initialize_1 ()
*** 567,573 ****
    if (__malloc_initialize_hook)
      (*__malloc_initialize_hook) ();
  
! #ifdef USE_PTHREAD
    {
      pthread_mutexattr_t attr;
  
--- 576,584 ----
    if (__malloc_initialize_hook)
      (*__malloc_initialize_hook) ();
  
!   /* We don't use recursive mutex because pthread_mutexattr_init may
!      call malloc internally.  */
! #if 0 /* defined (USE_PTHREAD) */
    {
      pthread_mutexattr_t attr;
  
*************** static int morecore_recursing;
*** 616,624 ****
  
  /* Get neatly aligned memory, initializing or
     growing the heap info table as necessary. */
! static __ptr_t morecore PP ((__malloc_size_t));
  static __ptr_t
! morecore (size)
       __malloc_size_t size;
  {
    __ptr_t result;
--- 627,635 ----
  
  /* Get neatly aligned memory, initializing or
     growing the heap info table as necessary. */
! static __ptr_t morecore_nolock PP ((__malloc_size_t));
  static __ptr_t
! morecore_nolock (size)
       __malloc_size_t size;
  {
    __ptr_t result;
*************** morecore (size)
*** 661,667 ****
  	     `morecore_recursing' flag and return null.  */
  	  int save = errno;	/* Don't want to clobber errno with ENOMEM.  */
  	  morecore_recursing = 1;
! 	  newinfo = (malloc_info *) _realloc_internal
  	    (_heapinfo, newsize * sizeof (malloc_info));
  	  morecore_recursing = 0;
  	  if (newinfo == NULL)
--- 672,678 ----
  	     `morecore_recursing' flag and return null.  */
  	  int save = errno;	/* Don't want to clobber errno with ENOMEM.  */
  	  morecore_recursing = 1;
! 	  newinfo = (malloc_info *) _realloc_internal_nolock
  	    (_heapinfo, newsize * sizeof (malloc_info));
  	  morecore_recursing = 0;
  	  if (newinfo == NULL)
*************** morecore (size)
*** 717,723 ****
        /* Reset _heaplimit so _free_internal never decides
  	 it can relocate or resize the info table.  */
        _heaplimit = 0;
!       _free_internal (oldinfo);
        PROTECT_MALLOC_STATE (0);
  
        /* The new heap limit includes the new table just allocated.  */
--- 728,734 ----
        /* Reset _heaplimit so _free_internal never decides
  	 it can relocate or resize the info table.  */
        _heaplimit = 0;
!       _free_internal_nolock (oldinfo);
        PROTECT_MALLOC_STATE (0);
  
        /* The new heap limit includes the new table just allocated.  */
*************** morecore (size)
*** 732,738 ****
  
  /* Allocate memory from the heap.  */
  __ptr_t
! _malloc_internal (size)
       __malloc_size_t size;
  {
    __ptr_t result;
--- 743,749 ----
  
  /* Allocate memory from the heap.  */
  __ptr_t
! _malloc_internal_nolock (size)
       __malloc_size_t size;
  {
    __ptr_t result;
*************** _malloc_internal (size)
*** 752,758 ****
      return NULL;
  #endif
  
-   LOCK ();
    PROTECT_MALLOC_STATE (0);
  
    if (size < sizeof (struct list))
--- 763,768 ----
*************** _malloc_internal (size)
*** 802,809 ****
  	  /* No free fragments of the desired size, so get a new block
  	     and break it into fragments, returning the first.  */
  #ifdef GC_MALLOC_CHECK
! 	  result = _malloc_internal (BLOCKSIZE);
  	  PROTECT_MALLOC_STATE (0);
  #else
  	  result = malloc (BLOCKSIZE);
  #endif
--- 812,821 ----
  	  /* No free fragments of the desired size, so get a new block
  	     and break it into fragments, returning the first.  */
  #ifdef GC_MALLOC_CHECK
! 	  result = _malloc_internal_nolock (BLOCKSIZE);
  	  PROTECT_MALLOC_STATE (0);
+ #elif defined (USE_PTHREAD)
+ 	  result = _malloc_internal_nolock (BLOCKSIZE);
  #else
  	  result = malloc (BLOCKSIZE);
  #endif
*************** _malloc_internal (size)
*** 874,880 ****
   		  _heaplimit += wantblocks - lastblocks;
  		  continue;
  		}
! 	      result = morecore (wantblocks * BLOCKSIZE);
  	      if (result == NULL)
  		goto out;
  	      block = BLOCK (result);
--- 886,892 ----
   		  _heaplimit += wantblocks - lastblocks;
  		  continue;
  		}
! 	      result = morecore_nolock (wantblocks * BLOCKSIZE);
  	      if (result == NULL)
  		goto out;
  	      block = BLOCK (result);
*************** _malloc_internal (size)
*** 932,938 ****
--- 944,962 ----
  
    PROTECT_MALLOC_STATE (1);
   out:
+   return result;
+ }
+ 
+ __ptr_t
+ _malloc_internal (size)
+      __malloc_size_t size;
+ {
+   __ptr_t result;
+ 
+   LOCK ();
+   result = _malloc_internal_nolock (size);
    UNLOCK ();
+ 
    return result;
  }
  
*************** __ptr_t
*** 940,949 ****
  malloc (size)
       __malloc_size_t size;
  {
    if (!__malloc_initialized && !__malloc_initialize ())
      return NULL;
  
!   return (__malloc_hook != NULL ? *__malloc_hook : _malloc_internal) (size);
  }
  \f
  #ifndef _LIBC
--- 964,979 ----
  malloc (size)
       __malloc_size_t size;
  {
+   __ptr_t (*hook) (__malloc_size_t);
+ 
    if (!__malloc_initialized && !__malloc_initialize ())
      return NULL;
  
!   /* 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);
  }
  \f
  #ifndef _LIBC
*************** void (*__free_hook) PP ((__ptr_t __ptr))
*** 1024,1032 ****
  struct alignlist *_aligned_blocks = NULL;
  
  /* Return memory to the heap.
!    Like `free' but don't call a __free_hook if there is one.  */
  void
! _free_internal (ptr)
       __ptr_t ptr;
  {
    int type;
--- 1054,1062 ----
  struct alignlist *_aligned_blocks = NULL;
  
  /* Return memory to the heap.
!    Like `_free_internal' but don't lock mutex.  */
  void
! _free_internal_nolock (ptr)
       __ptr_t ptr;
  {
    int type;
*************** _free_internal (ptr)
*** 1043,1051 ****
    if (ptr == NULL)
      return;
  
-   LOCK ();
    PROTECT_MALLOC_STATE (0);
  
    for (l = _aligned_blocks; l != NULL; l = l->next)
      if (l->aligned == ptr)
        {
--- 1073,1081 ----
    if (ptr == NULL)
      return;
  
    PROTECT_MALLOC_STATE (0);
  
+   LOCK_ALIGNED_BLOCKS ();
    for (l = _aligned_blocks; l != NULL; l = l->next)
      if (l->aligned == ptr)
        {
*************** _free_internal (ptr)
*** 1053,1058 ****
--- 1083,1089 ----
  	ptr = l->exact;
  	break;
        }
+   UNLOCK_ALIGNED_BLOCKS ();
  
    block = BLOCK (ptr);
  
*************** _free_internal (ptr)
*** 1158,1164 ****
  		 table's blocks to the system before we have copied them to
  		 the new location.  */
  	      _heaplimit = 0;
! 	      _free_internal (_heapinfo);
  	      _heaplimit = oldlimit;
  
  	      /* Tell malloc to search from the beginning of the heap for
--- 1189,1195 ----
  		 table's blocks to the system before we have copied them to
  		 the new location.  */
  	      _heaplimit = 0;
! 	      _free_internal_nolock (_heapinfo);
  	      _heaplimit = oldlimit;
  
  	      /* Tell malloc to search from the beginning of the heap for
*************** _free_internal (ptr)
*** 1166,1173 ****
  	      _heapindex = 0;
  
  	      /* Allocate new space for the info table and move its data.  */
! 	      newinfo = (malloc_info *) _malloc_internal (info_blocks
! 							  * BLOCKSIZE);
  	      PROTECT_MALLOC_STATE (0);
  	      memmove (newinfo, _heapinfo, info_blocks * BLOCKSIZE);
  	      _heapinfo = newinfo;
--- 1197,1204 ----
  	      _heapindex = 0;
  
  	      /* Allocate new space for the info table and move its data.  */
! 	      newinfo = (malloc_info *) _malloc_internal_nolock (info_blocks
! 								 * BLOCKSIZE);
  	      PROTECT_MALLOC_STATE (0);
  	      memmove (newinfo, _heapinfo, info_blocks * BLOCKSIZE);
  	      _heapinfo = newinfo;
*************** _free_internal (ptr)
*** 1230,1237 ****
  	  _chunks_free -= BLOCKSIZE >> type;
  	  _bytes_free -= BLOCKSIZE;
  
! #ifdef GC_MALLOC_CHECK
! 	  _free_internal (ADDRESS (block));
  #else
  	  free (ADDRESS (block));
  #endif
--- 1261,1268 ----
  	  _chunks_free -= BLOCKSIZE >> type;
  	  _bytes_free -= BLOCKSIZE;
  
! #if defined (GC_MALLOC_CHECK) || defined (USE_PTHREAD)
! 	  _free_internal_nolock (ADDRESS (block));
  #else
  	  free (ADDRESS (block));
  #endif
*************** _free_internal (ptr)
*** 1269,1274 ****
--- 1300,1315 ----
      }
  
    PROTECT_MALLOC_STATE (1);
+ }
+ 
+ /* Return memory to the heap.
+    Like `free' but don't call a __free_hook if there is one.  */
+ void
+ _free_internal (ptr)
+      __ptr_t ptr;
+ {
+   LOCK ();
+   _free_internal_nolock (ptr);
    UNLOCK ();
  }
  
*************** FREE_RETURN_TYPE
*** 1278,1285 ****
  free (ptr)
       __ptr_t ptr;
  {
!   if (__free_hook != NULL)
!     (*__free_hook) (ptr);
    else
      _free_internal (ptr);
  }
--- 1319,1328 ----
  free (ptr)
       __ptr_t ptr;
  {
!   void (*hook) (__ptr_t) = __free_hook;
! 
!   if (hook != NULL)
!     (*hook) (ptr);
    else
      _free_internal (ptr);
  }
*************** __ptr_t (*__realloc_hook) PP ((__ptr_t _
*** 1415,1421 ****
     new region.  This module has incestuous knowledge of the
     internals of both free and malloc. */
  __ptr_t
! _realloc_internal (ptr, size)
       __ptr_t ptr;
       __malloc_size_t size;
  {
--- 1458,1464 ----
     new region.  This module has incestuous knowledge of the
     internals of both free and malloc. */
  __ptr_t
! _realloc_internal_nolock (ptr, size)
       __ptr_t ptr;
       __malloc_size_t size;
  {
*************** _realloc_internal (ptr, size)
*** 1425,1439 ****
  
    if (size == 0)
      {
!       _free_internal (ptr);
!       return _malloc_internal (0);
      }
    else if (ptr == NULL)
!     return _malloc_internal (size);
  
    block = BLOCK (ptr);
  
-   LOCK ();
    PROTECT_MALLOC_STATE (0);
  
    type = _heapinfo[block].busy.type;
--- 1468,1481 ----
  
    if (size == 0)
      {
!       _free_internal_nolock (ptr);
!       return _malloc_internal_nolock (0);
      }
    else if (ptr == NULL)
!     return _malloc_internal_nolock (size);
  
    block = BLOCK (ptr);
  
    PROTECT_MALLOC_STATE (0);
  
    type = _heapinfo[block].busy.type;
*************** _realloc_internal (ptr, size)
*** 1443,1453 ****
        /* Maybe reallocate a large block to a small fragment.  */
        if (size <= BLOCKSIZE / 2)
  	{
! 	  result = _malloc_internal (size);
  	  if (result != NULL)
  	    {
  	      memcpy (result, ptr, size);
! 	      _free_internal (ptr);
  	      goto out;
  	    }
  	}
--- 1485,1495 ----
        /* Maybe reallocate a large block to a small fragment.  */
        if (size <= BLOCKSIZE / 2)
  	{
! 	  result = _malloc_internal_nolock (size);
  	  if (result != NULL)
  	    {
  	      memcpy (result, ptr, size);
! 	      _free_internal_nolock (ptr);
  	      goto out;
  	    }
  	}
*************** _realloc_internal (ptr, size)
*** 1467,1473 ****
  	     Now we will free this chunk; increment the statistics counter
  	     so it doesn't become wrong when _free_internal decrements it.  */
  	  ++_chunks_used;
! 	  _free_internal (ADDRESS (block + blocks));
  	  result = ptr;
  	}
        else if (blocks == _heapinfo[block].busy.info.size)
--- 1509,1515 ----
  	     Now we will free this chunk; increment the statistics counter
  	     so it doesn't become wrong when _free_internal decrements it.  */
  	  ++_chunks_used;
! 	  _free_internal_nolock (ADDRESS (block + blocks));
  	  result = ptr;
  	}
        else if (blocks == _heapinfo[block].busy.info.size)
*************** _realloc_internal (ptr, size)
*** 1482,1489 ****
  	  /* Prevent free from actually returning memory to the system.  */
  	  oldlimit = _heaplimit;
  	  _heaplimit = 0;
! 	  _free_internal (ptr);
! 	  result = _malloc_internal (size);
  	  PROTECT_MALLOC_STATE (0);
  	  if (_heaplimit == 0)
  	    _heaplimit = oldlimit;
--- 1524,1531 ----
  	  /* Prevent free from actually returning memory to the system.  */
  	  oldlimit = _heaplimit;
  	  _heaplimit = 0;
! 	  _free_internal_nolock (ptr);
! 	  result = _malloc_internal_nolock (size);
  	  PROTECT_MALLOC_STATE (0);
  	  if (_heaplimit == 0)
  	    _heaplimit = oldlimit;
*************** _realloc_internal (ptr, size)
*** 1493,1505 ****
  		 the thing we just freed.  Unfortunately it might
  		 have been coalesced with its neighbors.  */
  	      if (_heapindex == block)
! 	        (void) _malloc_internal (blocks * BLOCKSIZE);
  	      else
  		{
  		  __ptr_t previous
! 		    = _malloc_internal ((block - _heapindex) * BLOCKSIZE);
! 		  (void) _malloc_internal (blocks * BLOCKSIZE);
! 		  _free_internal (previous);
  		}
  	      goto out;
  	    }
--- 1535,1547 ----
  		 the thing we just freed.  Unfortunately it might
  		 have been coalesced with its neighbors.  */
  	      if (_heapindex == block)
! 	        (void) _malloc_internal_nolock (blocks * BLOCKSIZE);
  	      else
  		{
  		  __ptr_t previous
! 		    = _malloc_internal_nolock ((block - _heapindex) * BLOCKSIZE);
! 		  (void) _malloc_internal_nolock (blocks * BLOCKSIZE);
! 		  _free_internal_nolock (previous);
  		}
  	      goto out;
  	    }
*************** _realloc_internal (ptr, size)
*** 1519,1536 ****
  	{
  	  /* The new size is different; allocate a new space,
  	     and copy the lesser of the new size and the old. */
! 	  result = _malloc_internal (size);
  	  if (result == NULL)
  	    goto out;
  	  memcpy (result, ptr, min (size, (__malloc_size_t) 1 << type));
! 	  _free_internal (ptr);
  	}
        break;
      }
  
    PROTECT_MALLOC_STATE (1);
   out:
    UNLOCK ();
    return result;
  }
  
--- 1561,1591 ----
  	{
  	  /* The new size is different; allocate a new space,
  	     and copy the lesser of the new size and the old. */
! 	  result = _malloc_internal_nolock (size);
  	  if (result == NULL)
  	    goto out;
  	  memcpy (result, ptr, min (size, (__malloc_size_t) 1 << type));
! 	  _free_internal_nolock (ptr);
  	}
        break;
      }
  
    PROTECT_MALLOC_STATE (1);
   out:
+   return result;
+ }
+ 
+ __ptr_t
+ _realloc_internal (ptr, size)
+      __ptr_t ptr;
+      __malloc_size_t size;
+ {
+   __ptr_t result;
+ 
+   LOCK();
+   result = _realloc_internal_nolock (ptr, size);
    UNLOCK ();
+ 
    return result;
  }
  
*************** realloc (ptr, size)
*** 1539,1549 ****
       __ptr_t ptr;
       __malloc_size_t size;
  {
    if (!__malloc_initialized && !__malloc_initialize ())
      return NULL;
  
!   return (__realloc_hook != NULL ? *__realloc_hook : _realloc_internal)
!     (ptr, size);
  }
  /* Copyright (C) 1991, 1992, 1994 Free Software Foundation, Inc.
  
--- 1594,1606 ----
       __ptr_t ptr;
       __malloc_size_t size;
  {
+   __ptr_t (*hook) (__ptr_t, __malloc_size_t);
+ 
    if (!__malloc_initialized && !__malloc_initialize ())
      return NULL;
  
!   hook = __realloc_hook;
!   return (hook != NULL ? *hook : _realloc_internal) (ptr, size);
  }
  /* Copyright (C) 1991, 1992, 1994 Free Software Foundation, Inc.
  
*************** memalign (alignment, size)
*** 1681,1689 ****
  {
    __ptr_t result;
    unsigned long int adj, lastadj;
  
!   if (__memalign_hook)
!     return (*__memalign_hook) (alignment, size);
  
    /* Allocate a block with enough extra space to pad the block with up to
       (ALIGNMENT - 1) bytes if necessary.  */
--- 1738,1747 ----
  {
    __ptr_t result;
    unsigned long int adj, lastadj;
+   __ptr_t (*hook) (__malloc_size_t, __malloc_size_t) = __memalign_hook;
  
!   if (hook)
!     return (*hook) (alignment, size);
  
    /* Allocate a block with enough extra space to pad the block with up to
       (ALIGNMENT - 1) bytes if necessary.  */
*************** memalign (alignment, size)
*** 1718,1723 ****
--- 1776,1782 ----
  	 of an allocated block.  */
  
        struct alignlist *l;
+       LOCK_ALIGNED_BLOCKS ();
        for (l = _aligned_blocks; l != NULL; l = l->next)
  	if (l->aligned == NULL)
  	  /* This slot is free.  Use it.  */
*************** memalign (alignment, size)
*** 1725,1740 ****
        if (l == NULL)
  	{
  	  l = (struct alignlist *) malloc (sizeof (struct alignlist));
! 	  if (l == NULL)
  	    {
! 	      free (result);
! 	      return NULL;
  	    }
- 	  l->next = _aligned_blocks;
- 	  _aligned_blocks = l;
  	}
!       l->exact = result;
!       result = l->aligned = (char *) result + alignment - adj;
      }
  
    return result;
--- 1784,1806 ----
        if (l == NULL)
  	{
  	  l = (struct alignlist *) malloc (sizeof (struct alignlist));
! 	  if (l != NULL)
  	    {
! 	      l->next = _aligned_blocks;
! 	      _aligned_blocks = l;
  	    }
  	}
!       if (l != NULL)
! 	{
! 	  l->exact = result;
! 	  result = l->aligned = (char *) result + alignment - adj;
! 	}
!       UNLOCK_ALIGNED_BLOCKS ();
!       if (l == NULL)
! 	{
! 	  free (result);
! 	  result = NULL;
! 	}
      }
  
    return result;

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-18  1:11 ` YAMAMOTO Mitsuharu
@ 2007-06-21 10:13   ` Jan Djärv
  2007-06-21 11:36     ` YAMAMOTO Mitsuharu
  2007-06-25  5:33     ` Ken Raeburn
  2007-06-24 23:47   ` Richard Stallman
  1 sibling, 2 replies; 23+ messages in thread
From: Jan Djärv @ 2007-06-21 10:13 UTC (permalink / raw)
  To: YAMAMOTO Mitsuharu; +Cc: rms, emacs-devel



YAMAMOTO Mitsuharu skrev:
>>>>>> On Sun, 17 Jun 2007 17:49:28 -0400, Richard Stallman <rms@gnu.org> said:
> 
>> Would someone else (other that Mitsuharu) please study this patch to
>> check whether it is really correct?  Things like this can be tricky.
> 
> Please take a look at the following one instead.  It tries to fix the
> following problems of gmalloc.c with HAVE_GTK_AND_PTHREAD in Emacs 22.1.
> 
> * HAVE_GTK_AND_PTHREAD was checked before including config.h.
> * malloc_initialize_1 called pthread_mutexattr_init that may call malloc.
> * _aligned_blocks was not protected.
> * __malloc_hook etc. may be modified between its NULL-check and the use.

The patch was corrupted by some mailer so I could not apply it, but:

!   /* 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.

	Jan D.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-21 10:13   ` Jan Djärv
@ 2007-06-21 11:36     ` YAMAMOTO Mitsuharu
  2007-06-25  5:33     ` Ken Raeburn
  1 sibling, 0 replies; 23+ messages in thread
From: YAMAMOTO Mitsuharu @ 2007-06-21 11:36 UTC (permalink / raw)
  To: Jan Djärv; +Cc: rms, emacs-devel

>>>>> On Thu, 21 Jun 2007 12:13:29 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

> The patch was corrupted by some mailer so I could not apply it, but:

> !   /* 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.

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

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-18  1:11 ` YAMAMOTO Mitsuharu
  2007-06-21 10:13   ` Jan Djärv
@ 2007-06-24 23:47   ` Richard Stallman
  1 sibling, 0 replies; 23+ messages in thread
From: Richard Stallman @ 2007-06-24 23:47 UTC (permalink / raw)
  To: YAMAMOTO Mitsuharu; +Cc: emacs-devel

Since nobody has found a real problem with your patch,
would you please install it in Emacs 22 and in the trunk?

Please ack when it is installed.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-21 10:13   ` Jan Djärv
  2007-06-21 11:36     ` YAMAMOTO Mitsuharu
@ 2007-06-25  5:33     ` Ken Raeburn
  2007-06-25  8:30       ` YAMAMOTO Mitsuharu
  1 sibling, 1 reply; 23+ messages in thread
From: Ken Raeburn @ 2007-06-25  5:33 UTC (permalink / raw)
  To: emacs-devel

On Jun 21, 2007, at 06:13, Jan Djärv wrote:
> YAMAMOTO Mitsuharu skrev:
>>>>>>> On Sun, 17 Jun 2007 17:49:28 -0400, Richard Stallman  
>>>>>>> <rms@gnu.org> said:
>>> Would someone else (other that Mitsuharu) please study this patch to
>>> check whether it is really correct?  Things like this can be tricky.
>> Please take a look at the following one instead.  It tries to fix the
>> following problems of gmalloc.c with HAVE_GTK_AND_PTHREAD in Emacs  
>> 22.1.
>> * HAVE_GTK_AND_PTHREAD was checked before including config.h.
>> * malloc_initialize_1 called pthread_mutexattr_init that may call  
>> malloc.
>> * _aligned_blocks was not protected.
>> * __malloc_hook etc. may be modified between its NULL-check and  
>> the use.
>
> The patch was corrupted by some mailer so I could not apply it, but:
>
> !   /* 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.)  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.

Ken

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-25  5:33     ` Ken Raeburn
@ 2007-06-25  8:30       ` YAMAMOTO Mitsuharu
  2007-06-25  9:30         ` Ken Raeburn
  0 siblings, 1 reply; 23+ messages in thread
From: YAMAMOTO Mitsuharu @ 2007-06-25  8:30 UTC (permalink / raw)
  To: Ken Raeburn; +Cc: emacs-devel

>>>>> On Mon, 25 Jun 2007 01:33:59 -0400, Ken Raeburn <raeburn@raeburn.org> 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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-25  8:30       ` YAMAMOTO Mitsuharu
@ 2007-06-25  9:30         ` Ken Raeburn
  2007-06-25 10:05           ` YAMAMOTO Mitsuharu
  0 siblings, 1 reply; 23+ messages in thread
From: Ken Raeburn @ 2007-06-25  9:30 UTC (permalink / raw)
  To: YAMAMOTO Mitsuharu; +Cc: emacs-devel

On Jun 25, 2007, at 04:30, YAMAMOTO Mitsuharu wrote:
>> 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

I'd believe it could be, sure.  But if that code were produced with  
gcc -O2, I'd be disappointed.  Other compilers ... eh, some of them  
aren't that good. :-)

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

Yes, I think keeping the current glibc interface -- at least, as the  
one we actually use -- seems like a poor idea.  Though the change  
should be coordinated with glibc maintainers, of course.

Ken

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-25  9:30         ` Ken Raeburn
@ 2007-06-25 10:05           ` YAMAMOTO Mitsuharu
  2007-06-25 15:46             ` Richard Stallman
  2007-06-25 15:46             ` Richard Stallman
  0 siblings, 2 replies; 23+ messages in thread
From: YAMAMOTO Mitsuharu @ 2007-06-25 10:05 UTC (permalink / raw)
  To: Ken Raeburn; +Cc: emacs-devel

>>>>> On Mon, 25 Jun 2007 05:30:14 -0400, Ken Raeburn <raeburn@raeburn.org> said:

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

> Yes, I think keeping the current glibc interface -- at least, as the
> one we actually use -- seems like a poor idea.  Though the change
> should be coordinated with glibc maintainers, of course.

It looks like a medium-term solution.  Then we should also consider
options other than maintaining the current gmalloc.c.  Namely,

  1) Include a newer version of GNU malloc (hopefully with a better
     interface for hooks).
  2) Use the system malloc if pthreads are needed.
     (emacs_blocked_malloc etc. will be unnecessary when SYNC_INPUT
      becomes default.)

For a short-term solution, do you agree to install my patch for Emacs
22.2?  Unfortunately we couldn't notice that gmalloc.c was
thread-unsafe until very recently, and we needed an immediate solution
then (although it failed to solve the problem actually).

http://lists.gnu.org/archive/html/emacs-devel/2007-03/msg00856.html

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-25 10:05           ` YAMAMOTO Mitsuharu
@ 2007-06-25 15:46             ` Richard Stallman
  2007-06-26  3:45               ` YAMAMOTO Mitsuharu
  2007-06-25 15:46             ` Richard Stallman
  1 sibling, 1 reply; 23+ messages in thread
From: Richard Stallman @ 2007-06-25 15:46 UTC (permalink / raw)
  To: YAMAMOTO Mitsuharu; +Cc: raeburn, emacs-devel

    For a short-term solution, do you agree to install my patch for Emacs
    22.2?  Unfortunately we couldn't notice that gmalloc.c was
    thread-unsafe until very recently, and we needed an immediate solution
    then (although it failed to solve the problem actually).

I agree we need a solution for this now.  I am not sure (from
following the discussion with one eye) whether your solution actually
works, or whether it needs further change, or whether (if so) you've
done the further change.

What is the status of your fix?

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-25 10:05           ` YAMAMOTO Mitsuharu
  2007-06-25 15:46             ` Richard Stallman
@ 2007-06-25 15:46             ` Richard Stallman
  2007-06-25 16:33               ` Stefan Monnier
  1 sibling, 1 reply; 23+ messages in thread
From: Richard Stallman @ 2007-06-25 15:46 UTC (permalink / raw)
  To: YAMAMOTO Mitsuharu; +Cc: raeburn, emacs-devel

      1) Include a newer version of GNU malloc (hopefully with a better
	 interface for hooks).

I have nothing against that.

      2) Use the system malloc if pthreads are needed.
	 (emacs_blocked_malloc etc. will be unnecessary when SYNC_INPUT
	  becomes default.)

There is a serious problem with SYNC_INPUT, which is the reason it has
not been made the default.  The problem is that it makes Emacs unable
to update the display except when it can read input.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-25 15:46             ` Richard Stallman
@ 2007-06-25 16:33               ` Stefan Monnier
  2007-06-25 17:04                 ` Chong Yidong
  2007-06-26 16:58                 ` Richard Stallman
  0 siblings, 2 replies; 23+ messages in thread
From: Stefan Monnier @ 2007-06-25 16:33 UTC (permalink / raw)
  To: rms; +Cc: raeburn, YAMAMOTO Mitsuharu, emacs-devel

> There is a serious problem with SYNC_INPUT, which is the reason it has
> not been made the default.  The problem is that it makes Emacs unable
> to update the display except when it can read input.

You are still somewhat unclear about how SYNC_INPUT works.  It can update
the display just fine even when Emacs can't read input.  The only times when
it can't update the display is when it's stuck in an endless loop with no
QUIT or UNBLOCK_INPUT in sight.


        Stefan

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-25 16:33               ` Stefan Monnier
@ 2007-06-25 17:04                 ` Chong Yidong
  2007-06-26 16:58                   ` Richard Stallman
  2007-06-26 16:58                 ` Richard Stallman
  1 sibling, 1 reply; 23+ messages in thread
From: Chong Yidong @ 2007-06-25 17:04 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: raeburn, rms, YAMAMOTO Mitsuharu, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> There is a serious problem with SYNC_INPUT, which is the reason it has
>> not been made the default.  The problem is that it makes Emacs unable
>> to update the display except when it can read input.
>
> You are still somewhat unclear about how SYNC_INPUT works.  It can update
> the display just fine even when Emacs can't read input.  The only times when
> it can't update the display is when it's stuck in an endless loop with no
> QUIT or UNBLOCK_INPUT in sight.

I was under the impression, from the last time this was discussed on
emacs-devel, that the plan was to move to SYNC_INPUT after the Emacs
22.1 release.  If this is still the case, then I can go through the
Emacs sources to find and fix loops lacking QUIT.  Then we can make
the switch.

(On the other hand, it would be easier to do this after the unicode
merge.  I have several other cleanups that are also sitting around
waiting for the merge.)

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-25 15:46             ` Richard Stallman
@ 2007-06-26  3:45               ` YAMAMOTO Mitsuharu
  2007-06-26 22:48                 ` Richard Stallman
  0 siblings, 1 reply; 23+ messages in thread
From: YAMAMOTO Mitsuharu @ 2007-06-26  3:45 UTC (permalink / raw)
  To: rms; +Cc: raeburn, emacs-devel

>>>>> On Mon, 25 Jun 2007 11:46:05 -0400, Richard Stallman <rms@gnu.org> said:

>     For a short-term solution, do you agree to install my patch for
>     Emacs 22.2?  Unfortunately we couldn't notice that gmalloc.c was
>     thread-unsafe until very recently, and we needed an immediate
>     solution then (although it failed to solve the problem
>     actually).

> I agree we need a solution for this now.  I am not sure (from
> following the discussion with one eye) whether your solution
> actually works, or whether it needs further change, or whether (if
> so) you've done the further change.

> What is the status of your fix?

As for the issue on the hook variables such as __malloc_hook, it will
work at least as well as glibc malloc.  But neither is correct in a
strict sense.  I've just installed my patch to the trunk and the
EMACS_22_BASE branch with adding a comment below:

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

     Note: Strictly speaking, this is not a right solution.  We should
     use mutexes to access non-read-only variables that are shared
     among multiple threads.  We just leave it for compatibility with
     glibc malloc (i.e., assignments to __malloc_hook) for now.  */

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-25 16:33               ` Stefan Monnier
  2007-06-25 17:04                 ` Chong Yidong
@ 2007-06-26 16:58                 ` Richard Stallman
  1 sibling, 0 replies; 23+ messages in thread
From: Richard Stallman @ 2007-06-26 16:58 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: raeburn, mituharu, emacs-devel

    You are still somewhat unclear about how SYNC_INPUT works.  It can update
    the display just fine even when Emacs can't read input.  The only times when
    it can't update the display is when it's stuck in an endless loop with no
    QUIT or UNBLOCK_INPUT in sight.

I stand corrected.  In that case, let's make it the default.
As Yidong mentioned, we need to find such loops and fix them.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-25 17:04                 ` Chong Yidong
@ 2007-06-26 16:58                   ` Richard Stallman
  2007-06-26 21:20                     ` David Kastrup
  2007-06-26 23:35                     ` Chong Yidong
  0 siblings, 2 replies; 23+ messages in thread
From: Richard Stallman @ 2007-06-26 16:58 UTC (permalink / raw)
  To: Chong Yidong; +Cc: raeburn, monnier, mituharu, emacs-devel

    I was under the impression, from the last time this was discussed on
    emacs-devel, that the plan was to move to SYNC_INPUT after the Emacs
    22.1 release.  If this is still the case, then I can go through the
    Emacs sources to find and fix loops lacking QUIT.  Then we can make
    the switch.

Please do it.

    (On the other hand, it would be easier to do this after the unicode
    merge.  I have several other cleanups that are also sitting around
    waiting for the merge.)

How about doing it now in the Unicode-2 branch?

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-26 16:58                   ` Richard Stallman
@ 2007-06-26 21:20                     ` David Kastrup
  2007-06-26 23:01                       ` Jason Rumney
  2007-06-27 16:47                       ` Richard Stallman
  2007-06-26 23:35                     ` Chong Yidong
  1 sibling, 2 replies; 23+ messages in thread
From: David Kastrup @ 2007-06-26 21:20 UTC (permalink / raw)
  To: rms; +Cc: Chong Yidong, raeburn, monnier, mituharu, emacs-devel

Richard Stallman <rms@gnu.org> writes:

>     I was under the impression, from the last time this was discussed on
>     emacs-devel, that the plan was to move to SYNC_INPUT after the Emacs
>     22.1 release.  If this is still the case, then I can go through the
>     Emacs sources to find and fix loops lacking QUIT.  Then we can make
>     the switch.
>
> Please do it.
>
>     (On the other hand, it would be easier to do this after the unicode
>     merge.  I have several other cleanups that are also sitting around
>     waiting for the merge.)
>
> How about doing it now in the Unicode-2 branch?

Unless I am mistaken, we have some semimanual merge going from the
trunk to unicode-2 but not the other way round.  So putting stuff in
the trunk will tend to end up being less manual work.

Miles, Handa-san?  Am I mistaken here?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-26  3:45               ` YAMAMOTO Mitsuharu
@ 2007-06-26 22:48                 ` Richard Stallman
  0 siblings, 0 replies; 23+ messages in thread
From: Richard Stallman @ 2007-06-26 22:48 UTC (permalink / raw)
  To: YAMAMOTO Mitsuharu; +Cc: raeburn, emacs-devel

Thank you.

    As for the issue on the hook variables such as __malloc_hook, it will
    work at least as well as glibc malloc.  But neither is correct in a
    strict sense.

In practice, it is not crucial that this code be formally correct.
It is enough that it operate correctly on the platforms it is used on.

There are not very many modern platforms any more, and some of them
don't use gmalloc.  Would people like to check the modern platforms
and verify that there is not really any problem?

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-26 21:20                     ` David Kastrup
@ 2007-06-26 23:01                       ` Jason Rumney
  2007-06-27 16:47                       ` Richard Stallman
  1 sibling, 0 replies; 23+ messages in thread
From: Jason Rumney @ 2007-06-26 23:01 UTC (permalink / raw)
  To: David Kastrup; +Cc: rms, Chong Yidong, emacs-devel, raeburn, monnier, mituharu

David Kastrup wrote:
> Unless I am mistaken, we have some semimanual merge going from the
> trunk to unicode-2 but not the other way round.  So putting stuff in
> the trunk will tend to end up being less manual work.
>   

Only if the intention is to merge the change into the trunk separately
from the unicode branch merge.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-26 16:58                   ` Richard Stallman
  2007-06-26 21:20                     ` David Kastrup
@ 2007-06-26 23:35                     ` Chong Yidong
  2007-06-27  1:31                       ` Stefan Monnier
  2007-06-27 19:50                       ` Richard Stallman
  1 sibling, 2 replies; 23+ messages in thread
From: Chong Yidong @ 2007-06-26 23:35 UTC (permalink / raw)
  To: rms; +Cc: raeburn, monnier, mituharu, emacs-devel

Richard Stallman <rms@gnu.org> writes:

>     I was under the impression, from the last time this was discussed on
>     emacs-devel, that the plan was to move to SYNC_INPUT after the Emacs
>     22.1 release.  If this is still the case, then I can go through the
>     Emacs sources to find and fix loops lacking QUIT.  Then we can make
>     the switch.
>
> Please do it.
>
>     (On the other hand, it would be easier to do this after the unicode
>     merge.  I have several other cleanups that are also sitting around
>     waiting for the merge.)
>
> How about doing it now in the Unicode-2 branch?

Then it would have to be merged back into the trunk.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-26 23:35                     ` Chong Yidong
@ 2007-06-27  1:31                       ` Stefan Monnier
  2007-06-27 19:50                       ` Richard Stallman
  1 sibling, 0 replies; 23+ messages in thread
From: Stefan Monnier @ 2007-06-27  1:31 UTC (permalink / raw)
  To: Chong Yidong; +Cc: raeburn, rms, mituharu, emacs-devel

> Then it would have to be merged back into the trunk.

Given that the turnk is merged into the trunk, the "merge" of the unicode
branch into the trunk will be nothing more than a funny form or renaming
where the branch we used to call "unicode" now becomes "trunk".  So "merging
it back" will be a no-op, really.


        Stefan

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-26 21:20                     ` David Kastrup
  2007-06-26 23:01                       ` Jason Rumney
@ 2007-06-27 16:47                       ` Richard Stallman
  1 sibling, 0 replies; 23+ messages in thread
From: Richard Stallman @ 2007-06-27 16:47 UTC (permalink / raw)
  To: David Kastrup; +Cc: cyd, raeburn, monnier, mituharu, emacs-devel

    >     (On the other hand, it would be easier to do this after the unicode
    >     merge.  I have several other cleanups that are also sitting around
    >     waiting for the merge.)
    >
    > How about doing it now in the Unicode-2 branch?

    Unless I am mistaken, we have some semimanual merge going from the
    trunk to unicode-2 but not the other way round.  So putting stuff in
    the trunk will tend to end up being less manual work.

I presume the reason he wants to do these after the unicode-2 merge is
that they interact with the unicode-2 changes, and would have to be
done differently in the trunk and in unicode-2.  If so, doing them
now, only in unicode-2, would avoid the need for extra work.

If they don't interact, then maybe then can be done in the trunk now.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked]
  2007-06-26 23:35                     ` Chong Yidong
  2007-06-27  1:31                       ` Stefan Monnier
@ 2007-06-27 19:50                       ` Richard Stallman
  1 sibling, 0 replies; 23+ messages in thread
From: Richard Stallman @ 2007-06-27 19:50 UTC (permalink / raw)
  To: Chong Yidong; +Cc: raeburn, monnier, mituharu, emacs-devel

    > How about doing it now in the Unicode-2 branch?

    Then it would have to be merged back into the trunk.

Yes, along with the rest of unicode-2.  But that will be easy, right?
The changes in the trunk are getting merged into unicode-2, so when
we do that merge (in a few weeks, I think), it should be straightforward.

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2007-06-27 19:50 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-06-17 21:49 [mituharu@math.s.chiba-u.ac.jp: Re: emacs-22.1 with GTK dumps core when Gnome wigets clicked] Richard Stallman
2007-06-18  1:11 ` YAMAMOTO Mitsuharu
2007-06-21 10:13   ` Jan Djärv
2007-06-21 11:36     ` YAMAMOTO Mitsuharu
2007-06-25  5:33     ` Ken Raeburn
2007-06-25  8:30       ` YAMAMOTO Mitsuharu
2007-06-25  9:30         ` Ken Raeburn
2007-06-25 10:05           ` YAMAMOTO Mitsuharu
2007-06-25 15:46             ` Richard Stallman
2007-06-26  3:45               ` YAMAMOTO Mitsuharu
2007-06-26 22:48                 ` Richard Stallman
2007-06-25 15:46             ` Richard Stallman
2007-06-25 16:33               ` Stefan Monnier
2007-06-25 17:04                 ` Chong Yidong
2007-06-26 16:58                   ` Richard Stallman
2007-06-26 21:20                     ` David Kastrup
2007-06-26 23:01                       ` Jason Rumney
2007-06-27 16:47                       ` Richard Stallman
2007-06-26 23:35                     ` Chong Yidong
2007-06-27  1:31                       ` Stefan Monnier
2007-06-27 19:50                       ` Richard Stallman
2007-06-26 16:58                 ` Richard Stallman
2007-06-24 23:47   ` Richard Stallman

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).