* [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).