FYI, trunk bootstrap segfaults with nonzero MALLOC_PERTURB_

FYI, trunk bootstrap segfaults with nonzero MALLOC_PERTURB_

[Jim Meyering]

Just to let you know that I'm once again seeing temacs segfault
when MALLOC_PERTURB_ is nonzero.  I was able to bootstrap by with
MALLOC_PERTURB_=0, but with it set to a nonzero value, temacs gets the
(sporadically usual, over the years, now) segfault.

This is on Fedora 17/x86_64 using gcc version 4.8.0 20120604.

When I use F17's current default gcc (version 4.7.0 20120507),
(still with nonzero MALLOC_PERTURB_) I get a slightly different failure:

    make[3]: *** [dired-aux.elc] Segmentation fault (core dumped)

Re: FYI, trunk bootstrap segfaults with nonzero MALLOC_PERTURB_

[Paul Eggert]

Thanks, I sort of reproduced that and filed a bug report
at <http://bugs.gnu.org/11662>.  Could be anything but I
suspect the recent changes to vector allocation.

Re: FYI, trunk bootstrap segfaults with nonzero MALLOC_PERTURB_

[Dmitry Antipov]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

On 06/10/2012 02:44 AM, Paul Eggert wrote:

> Thanks, I sort of reproduced that and filed a bug report
> at<http://bugs.gnu.org/11662>.  Could be anything but I
> suspect the recent changes to vector allocation.

Not reproduced with MALLOC_PERTURB_219 and MALLOC_CHECK_=[whatever nonzero]
on Fedora 16 with gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) and glibc
2.14.90-24.fc16.7.

Can someone try to rule out new vector allocation code with the patch attached
and see whether crash is affected?

Dmitry

[-- Attachment #2: disable_new_vector_alloc.patch --]
[-- Type: text/plain, Size: 1707 bytes --]

=== modified file 'src/alloc.c'
--- src/alloc.c	2012-06-13 00:26:40 +0000
+++ src/alloc.c	2012-06-13 11:21:25 +0000
@@ -491,6 +491,7 @@
   memory_full (nbytes);
 #endif
 
+  abort ();
   /* This used to call error, but if we've run out of memory, we could
      get infinite recursion trying to build the string.  */
   xsignal (Qnil, Vmemory_signal_data);
@@ -3014,6 +3015,8 @@
 {
   struct vector_block *block;
 
+  abort ();
+
 #ifdef DOUG_LEA_MALLOC
   mallopt (M_MMAP_MAX, 0);
 #endif
@@ -3052,6 +3055,8 @@
   struct vector_block *block;
   size_t index, restbytes;
 
+  abort ();
+
   eassert (VBLOCK_BYTES_MIN <= nbytes && nbytes <= VBLOCK_BYTES_MAX);
   eassert (nbytes % roundup_size == 0);
 
@@ -3135,6 +3140,8 @@
     {
       int free_this_block = 0;
 
+      abort ();
+
       for (vector = (struct Lisp_Vector *) block->data;
 	   VECTOR_IN_BLOCK (vector, block); vector = next)
 	{
@@ -3242,7 +3249,7 @@
 
   nbytes = header_size + len * word_size;
 
-  if (nbytes <= VBLOCK_BYTES_MAX)
+  if (0 && nbytes <= VBLOCK_BYTES_MAX)
     p = allocate_vector_from_block (vroundup (nbytes));
   else
     {
@@ -3785,6 +3792,7 @@
 #endif
     }
 
+  abort ();
   /* This used to call error, but if we've run out of memory, we could
      get infinite recursion trying to build the string.  */
   xsignal (Qnil, Vmemory_signal_data);
@@ -4369,6 +4377,8 @@
       struct vector_block *block = (struct vector_block *) m->start;
       struct Lisp_Vector *vector = (struct Lisp_Vector *) block->data;
 
+      abort ();
+
       /* P is in the block's allocation range.  Scan the block
 	 up to P and see whether P points to the start of some
 	 vector which is not on a free list.  FIXME: check whether

bug#11662: FYI, trunk bootstrap segfaults with nonzero MALLOC_PERTURB_

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 534 bytes --]

On 06/13/2012 05:06 AM, Dmitry Antipov wrote:

> Not reproduced with MALLOC_PERTURB_219 and MALLOC_CHECK_=[whatever nonzero]
> on Fedora 16 with gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) and glibc
> 2.14.90-24.fc16.7.
> 
> Can someone try to rule out new vector allocation code with the patch attached
> and see whether crash is affected?

I have not had a chance to get to this, but am replying now (with a copy
of your attached patch) to the bug-reporting address, so that this is
properly filed at <http://bugs.gnu.org/11662>.


[-- Attachment #2: disable_new_vector_alloc.patch --]
[-- Type: text/x-patch, Size: 1707 bytes --]

=== modified file 'src/alloc.c'
--- src/alloc.c	2012-06-13 00:26:40 +0000
+++ src/alloc.c	2012-06-13 11:21:25 +0000
@@ -491,6 +491,7 @@
   memory_full (nbytes);
 #endif
 
+  abort ();
   /* This used to call error, but if we've run out of memory, we could
      get infinite recursion trying to build the string.  */
   xsignal (Qnil, Vmemory_signal_data);
@@ -3014,6 +3015,8 @@
 {
   struct vector_block *block;
 
+  abort ();
+
 #ifdef DOUG_LEA_MALLOC
   mallopt (M_MMAP_MAX, 0);
 #endif
@@ -3052,6 +3055,8 @@
   struct vector_block *block;
   size_t index, restbytes;
 
+  abort ();
+
   eassert (VBLOCK_BYTES_MIN <= nbytes && nbytes <= VBLOCK_BYTES_MAX);
   eassert (nbytes % roundup_size == 0);
 
@@ -3135,6 +3140,8 @@
     {
       int free_this_block = 0;
 
+      abort ();
+
       for (vector = (struct Lisp_Vector *) block->data;
 	   VECTOR_IN_BLOCK (vector, block); vector = next)
 	{
@@ -3242,7 +3249,7 @@
 
   nbytes = header_size + len * word_size;
 
-  if (nbytes <= VBLOCK_BYTES_MAX)
+  if (0 && nbytes <= VBLOCK_BYTES_MAX)
     p = allocate_vector_from_block (vroundup (nbytes));
   else
     {
@@ -3785,6 +3792,7 @@
 #endif
     }
 
+  abort ();
   /* This used to call error, but if we've run out of memory, we could
      get infinite recursion trying to build the string.  */
   xsignal (Qnil, Vmemory_signal_data);
@@ -4369,6 +4377,8 @@
       struct vector_block *block = (struct vector_block *) m->start;
       struct Lisp_Vector *vector = (struct Lisp_Vector *) block->data;
 
+      abort ();
+
       /* P is in the block's allocation range.  Scan the block
 	 up to P and see whether P points to the start of some
 	 vector which is not on a free list.  FIXME: check whether

bug#11662: FYI, trunk bootstrap segfaults with nonzero MALLOC_PERTURB_

[Jim Meyering]

Paul Eggert wrote:

> On 06/13/2012 05:06 AM, Dmitry Antipov wrote:
>
>> Not reproduced with MALLOC_PERTURB_219 and MALLOC_CHECK_=[whatever nonzero]
>> on Fedora 16 with gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) and glibc
>> 2.14.90-24.fc16.7.
>>
>> Can someone try to rule out new vector allocation code with the patch attached
>> and see whether crash is affected?
>
> I have not had a chance to get to this, but am replying now (with a copy
> of your attached patch) to the bug-reporting address, so that this is
> properly filed at <http://bugs.gnu.org/11662>.

FYI, I am now using emacs bootstrapped with e.g., MALLOC_PERTURB_=48 (i.e.,
anything nonzero <= 255).  Thanks to you and Dmitry for all that cleanup work.