GNU bug report logs - #11662
trunk bootstrap segfaults with nonzero MALLOC_PERTURB_

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11662 in the body.
You can then email your comments to 11662 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: bug-gnu-emacs <at> gnu.org
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>
Subject: trunk bootstrap segfaults with nonzero MALLOC_PERTURB_
Date: Sat, 09 Jun 2012 15:41:33 -0700

This follows up on Jim Meyering's message at
<http://lists.gnu.org/archive/html/emacs-devel/2012-06/msg00159.html>.

On 06/09/2012 09:47 AM, Jim Meyering wrote:
> 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)

I ran with "export MALLOC_PERTURB_=219; export MALLOC_CHECK=3" on Fedora 15
and GCC 4.7.0, with an abort() in memory_full(), and got a similar failure,
with backtrace noted below.  This points in the neighborhood of the
recently-introduced vector allocation code, so I'll CC: this to Dmitry.
Note that there is no bug when compiling without optimization; the bug
occurs with the default optimization (-O2) but is not present if -O2
is not given.

Here's the patch I used to get the abort:

=== modified file 'src/alloc.c'
--- src/alloc.c	2012-06-08 09:58:43 +0000
+++ src/alloc.c	2012-06-09 22:13:15 +0000
@@ -493,6 +493,7 @@
 
   /* This used to call error, but if we've run out of memory, we could
      get infinite recursion trying to build the string.  */
+  abort ();
   xsignal (Qnil, Vmemory_signal_data);
 }
 
@@ -3800,6 +3801,7 @@
 
   /* This used to call error, but if we've run out of memory, we could
      get infinite recursion trying to build the string.  */
+  abort ();
   xsignal (Qnil, Vmemory_signal_data);
 }
 
and here's the backtrace:

(gdb) where
#0  0x0000003b308354f7 in kill () from /lib64/libc.so.6
#1  0x00000000004fcdfa in fatal_error_signal (sig=<optimized out>)
    at emacs.c:368
#2  fatal_error_signal (sig=<optimized out>) at emacs.c:338
#3  <signal handler called>
#4  0x0000003b308354f7 in kill () from /lib64/libc.so.6
#5  0x00000000004fc475 in abort () at emacs.c:396
#6  0x0000000000557f3a in memory_full (nbytes=nbytes <at> entry=201808)
    at alloc.c:3804
#7  0x0000000000558afb in lisp_malloc (nbytes=nbytes <at> entry=201808, 
    type=type <at> entry=MEM_TYPE_VECTORLIKE) at alloc.c:938
#8  0x000000000055978d in allocate_vectorlike (len=len <at> entry=25224)
    at alloc.c:3269
#9  0x0000000000559b73 in allocate_vectorlike (len=25224) at alloc.c:3257
#10 allocate_vector (len=len <at> entry=25224) at alloc.c:3298
#11 0x000000000057f5e3 in larger_vector (vec=16894405, 
    incr_min=incr_min <at> entry=8310, nitems_max=nitems_max <at> entry=-1)
    at fns.c:3445
#12 0x000000000057fffb in maybe_resize_hash_table (h=0xe1b358) at fns.c:3752
#13 hash_put (h=h <at> entry=0xe1b358, key=key <at> entry=18256518, 
    value=value <at> entry=11975170, hash=<optimized out>) at fns.c:3838
#14 0x0000000000580213 in Fputhash (key=key <at> entry=18256518, value=11975170, 
    table=<optimized out>) at fns.c:4509
#15 0x000000000058ab45 in print_preprocess (obj=18256518) at print.c:1183
#16 0x000000000058ac55 in print_preprocess (obj=18256550) at print.c:1199
#17 0x000000000058ab8e in print_preprocess (obj=obj <at> entry=13484741)
    at print.c:1211
#18 0x000000000058ed9f in print (obj=obj <at> entry=13484741, 
    printcharfun=printcharfun <at> entry=11975122, escapeflag=escapeflag <at> entry=1)
    at print.c:1085
#19 0x000000000058ff78 in Fprin1 (object=13484741, printcharfun=11975122)
    at print.c:570
#20 0x0000000000573129 in Ffuncall (nargs=<optimized out>, 
    args=args <at> entry=0x7fff24bc5db0) at eval.c:2824
#21 0x00000000005a9c70 in exec_byte_code (bytestr=<optimized out>, 
    vector=14932781, maxdepth=<optimized out>, args_template=<optimized out>, 
    nargs=nargs <at> entry=6, args=<optimized out>, args <at> entry=0xda40c8)
    at bytecode.c:784
#22 0x0000000000572b69 in funcall_lambda (fun=14932781, nargs=nargs <at> entry=6, 
    arg_vector=0xda40c8, arg_vector <at> entry=0x7fff24bc5f88) at eval.c:2987
#23 0x0000000000572f8b in Ffuncall (nargs=7, args=args <at> entry=0x7fff24bc5f80)
    at eval.c:2882
#24 0x00000000005a9c70 in exec_byte_code (bytestr=<optimized out>, 
    vector=15012229, maxdepth=<optimized out>, args_template=<optimized out>, 
    nargs=nargs <at> entry=5, args=<optimized out>, args <at> entry=0xda4a20)
    at bytecode.c:784
#25 0x0000000000572b69 in funcall_lambda (fun=15012229, nargs=nargs <at> entry=5, 
    arg_vector=0xda4a20, arg_vector <at> entry=0x7fff24bc6130) at eval.c:2987
#26 0x0000000000572f8b in Ffuncall (nargs=6, args=args <at> entry=0x7fff24bc6128)
    at eval.c:2882
#27 0x00000000005a9c70 in exec_byte_code (bytestr=<optimized out>, 
    vector=14513013, maxdepth=<optimized out>, args_template=<optimized out>, 
    nargs=nargs <at> entry=6, args=<optimized out>, args <at> entry=0xebb808)
    at bytecode.c:784
#28 0x0000000000572b69 in funcall_lambda (fun=14513013, nargs=nargs <at> entry=6, 
    arg_vector=0xebb808, arg_vector <at> entry=0x7fff24bc62f0) at eval.c:2987
#29 0x0000000000572f8b in Ffuncall (nargs=7, args=args <at> entry=0x7fff24bc62e8)
    at eval.c:2882
#30 0x00000000005a9c70 in exec_byte_code (bytestr=<optimized out>, 
    vector=12360997, maxdepth=<optimized out>, args_template=<optimized out>, 
    nargs=nargs <at> entry=5, args=<optimized out>, args <at> entry=0xebb770)
    at bytecode.c:784
#31 0x0000000000572b69 in funcall_lambda (fun=12360997, nargs=nargs <at> entry=5, 
    arg_vector=0xebb770, arg_vector <at> entry=0x7fff24bc64b0) at eval.c:2987
#32 0x0000000000572f8b in Ffuncall (nargs=6, args=args <at> entry=0x7fff24bc64a8)
    at eval.c:2882
#33 0x00000000005a9c70 in exec_byte_code (bytestr=<optimized out>, 
    vector=17842589, maxdepth=<optimized out>, args_template=<optimized out>, 
    nargs=nargs <at> entry=5, args=<optimized out>, args <at> entry=0xebb700)
    at bytecode.c:784
#34 0x0000000000572b69 in funcall_lambda (fun=17842589, nargs=nargs <at> entry=5, 
    arg_vector=0xebb700, arg_vector <at> entry=0x7fff24bc66a0) at eval.c:2987
#35 0x0000000000572f8b in Ffuncall (nargs=6, args=args <at> entry=0x7fff24bc6698)
    at eval.c:2882
#36 0x00000000005a9c70 in exec_byte_code (bytestr=<optimized out>, 
    vector=15727621, maxdepth=<optimized out>, args_template=<optimized out>, 
    nargs=nargs <at> entry=1, args=<optimized out>, args <at> entry=0xebb520)
    at bytecode.c:784
#37 0x0000000000572b69 in funcall_lambda (fun=15727621, nargs=nargs <at> entry=1, 
    arg_vector=0xebb520, arg_vector <at> entry=0x7fff24bc6860) at eval.c:2987
#38 0x0000000000572f8b in Ffuncall (nargs=2, args=args <at> entry=0x7fff24bc6858)
    at eval.c:2882
#39 0x00000000005a9c70 in exec_byte_code (bytestr=<optimized out>, 
    vector=17469325, maxdepth=<optimized out>, args_template=<optimized out>, 
    nargs=nargs <at> entry=1, args=<optimized out>, args <at> entry=0xda44e8)
    at bytecode.c:784
#40 0x0000000000572b69 in funcall_lambda (fun=17469325, nargs=nargs <at> entry=1, 
    arg_vector=0xda44e8, arg_vector <at> entry=0x7fff24bc69b8) at eval.c:2987
#41 0x0000000000572f8b in Ffuncall (nargs=2, args=args <at> entry=0x7fff24bc69b0)
    at eval.c:2882
#42 0x00000000005a9c70 in exec_byte_code (bytestr=<optimized out>, 
    vector=17469157, maxdepth=<optimized out>, args_template=<optimized out>, 
    nargs=nargs <at> entry=1, args=<optimized out>, args <at> entry=0xda4498)
    at bytecode.c:784
#43 0x0000000000572b69 in funcall_lambda (fun=17469157, nargs=nargs <at> entry=1, 
    arg_vector=0xda4498, arg_vector <at> entry=0x7fff24bc6b18) at eval.c:2987
#44 0x0000000000572f8b in Ffuncall (nargs=2, args=args <at> entry=0x7fff24bc6b10)
    at eval.c:2882
#45 0x00000000005a9c70 in exec_byte_code (bytestr=<optimized out>, 
    vector=14511245, maxdepth=<optimized out>, args_template=<optimized out>, 
    nargs=nargs <at> entry=0, args=<optimized out>, args <at> entry=0xda3730)
    at bytecode.c:784
#46 0x0000000000572b69 in funcall_lambda (fun=14511245, nargs=nargs <at> entry=0, 
    arg_vector=0xda3730, arg_vector <at> entry=0x7fff24bc6c70) at eval.c:2987
#47 0x0000000000572f8b in Ffuncall (nargs=1, args=args <at> entry=0x7fff24bc6c68)
    at eval.c:2882
#48 0x00000000005a9c70 in exec_byte_code (bytestr=<optimized out>, 
    vector=12420373, maxdepth=<optimized out>, args_template=<optimized out>, 
    nargs=nargs <at> entry=0, args=<optimized out>, args <at> entry=0xda3960)
    at bytecode.c:784
#49 0x0000000000572b69 in funcall_lambda (fun=12420373, nargs=nargs <at> entry=0, 
    arg_vector=0xda3960, arg_vector <at> entry=0x7fff24bc6db8) at eval.c:2987
#50 0x0000000000572f8b in Ffuncall (nargs=1, args=0x7fff24bc6db0)
    at eval.c:2882
#51 0x000000000057277a in eval_sub (form=form <at> entry=13010646) at eval.c:2140
#52 0x000000000057531f in internal_lisp_condition_case (var=15414098, 
    bodyform=13010646, handlers=13010358) at eval.c:1288
#53 0x00000000005aa5a3 in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs <at> entry=1, args=<optimized out>, 
    args <at> entry=0xda3608) at bytecode.c:980
#54 0x0000000000572b69 in funcall_lambda (fun=15013133, nargs=nargs <at> entry=1, 
    arg_vector=0xda3608, arg_vector <at> entry=0x7fff24bc7240) at eval.c:2987
#55 0x0000000000572f8b in Ffuncall (nargs=2, args=args <at> entry=0x7fff24bc7238)
    at eval.c:2882
#56 0x00000000005a9c70 in exec_byte_code (bytestr=<optimized out>, 
    vector=15528981, maxdepth=<optimized out>, args_template=<optimized out>, 
    nargs=nargs <at> entry=1, args=<optimized out>, args <at> entry=0xda2eb0)
    at bytecode.c:784
#57 0x0000000000572b69 in funcall_lambda (fun=15528981, nargs=nargs <at> entry=1, 
    arg_vector=0xda2eb0, arg_vector <at> entry=0x7fff24bc7400) at eval.c:2987
#58 0x0000000000572f8b in Ffuncall (nargs=2, args=args <at> entry=0x7fff24bc73f8)
    at eval.c:2882
#59 0x00000000005a9c70 in exec_byte_code (bytestr=<optimized out>, 
    vector=15533581, maxdepth=<optimized out>, args_template=<optimized out>, 
    nargs=nargs <at> entry=0, args=<optimized out>, args <at> entry=0xeb6148)
    at bytecode.c:784
#60 0x0000000000572b69 in funcall_lambda (fun=15533581, nargs=nargs <at> entry=0, 
    arg_vector=0xeb6148, arg_vector <at> entry=0x7fff24bc7558) at eval.c:2987
#61 0x0000000000572f8b in Ffuncall (nargs=1, args=0x7fff24bc7550)
    at eval.c:2882
#62 0x000000000057277a in eval_sub (form=form <at> entry=12894454) at eval.c:2140
#63 0x000000000057531f in internal_lisp_condition_case (var=12521906, 
    bodyform=12894454, handlers=12895078) at eval.c:1288
#64 0x00000000005aa5a3 in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs <at> entry=1, args=<optimized out>, 
    args <at> entry=0xeb60e0) at bytecode.c:980
#65 0x0000000000572b69 in funcall_lambda (fun=14589877, nargs=nargs <at> entry=1, 
    arg_vector=0xeb60e0, arg_vector <at> entry=0x7fff24bc7990) at eval.c:2987
#66 0x0000000000572f8b in Ffuncall (nargs=2, args=args <at> entry=0x7fff24bc7988)
    at eval.c:2882
#67 0x00000000005a9c70 in exec_byte_code (bytestr=<optimized out>, 
    vector=14589445, maxdepth=<optimized out>, args_template=<optimized out>, 
    nargs=nargs <at> entry=0, args=<optimized out>, args <at> entry=0xeb5fd8)
    at bytecode.c:784
#68 0x0000000000572b69 in funcall_lambda (fun=14589445, nargs=nargs <at> entry=0, 
    arg_vector=0xeb5fd8, arg_vector <at> entry=0x7fff24bc7b80) at eval.c:2987
#69 0x0000000000572f8b in Ffuncall (nargs=1, args=args <at> entry=0x7fff24bc7b78)
    at eval.c:2882
#70 0x00000000005a9c70 in exec_byte_code (bytestr=<optimized out>, 
    vector=9219269, maxdepth=<optimized out>, args_template=<optimized out>, 
    nargs=nargs <at> entry=1, args=<optimized out>, args <at> entry=0xa9d337)
    at bytecode.c:784
#71 0x0000000000572b69 in funcall_lambda (fun=9219269, nargs=nargs <at> entry=1, 
    arg_vector=0xa9d337, arg_vector <at> entry=0x7fff24bc7d00) at eval.c:2987
#72 0x0000000000572f8b in Ffuncall (nargs=2, args=args <at> entry=0x7fff24bc7cf8)
    at eval.c:2882
#73 0x00000000005a9c70 in exec_byte_code (bytestr=<optimized out>, 
    vector=9194589, maxdepth=<optimized out>, args_template=<optimized out>, 
    nargs=nargs <at> entry=0, args=<optimized out>, args <at> entry=0xa9f877)
    at bytecode.c:784
#74 0x0000000000572b69 in funcall_lambda (fun=9194589, nargs=nargs <at> entry=0, 
    arg_vector=0xa9f877, arg_vector <at> entry=0x7fff24bc7ed8) at eval.c:2987
#75 0x0000000000572f8b in Ffuncall (nargs=1, args=args <at> entry=0x7fff24bc7ed0)
    at eval.c:2882
#76 0x00000000005a9c70 in exec_byte_code (bytestr=<optimized out>, 
    vector=9189173, maxdepth=<optimized out>, args_template=<optimized out>, 
    nargs=nargs <at> entry=0, args=<optimized out>, args <at> entry=0xaa05f0)
    at bytecode.c:784
#77 0x0000000000572b69 in funcall_lambda (fun=9189173, fun <at> entry=9189085, 
    nargs=nargs <at> entry=0, arg_vector=0xaa05f0, arg_vector <at> entry=0x7fff24bc7fb0)
    at eval.c:2987
#78 0x000000000057205c in apply_lambda (fun=9189085, args=<optimized out>)
    at eval.c:2930
#79 0x0000000000572413 in eval_sub (form=form <at> entry=12488790) at eval.c:2232
#80 0x0000000000574c65 in Feval (form=12488790, lexical=<optimized out>)
    at eval.c:2022
#81 0x0000000000571553 in internal_condition_case (
    bfun=bfun <at> entry=0x4ffd00 <top_level_2>, handlers=12027074, 
    hfun=hfun <at> entry=0x5015a0 <cmd_error>) at eval.c:1334
#82 0x0000000000500236 in top_level_1 (ignore=ignore <at> entry=11975122)
    at keyboard.c:1172
#83 0x000000000057144b in internal_catch (
    tag=<error reading variable: Cannot access memory at address 0x5ffa>, 
    func=func <at> entry=0x5001d0 <top_level_1>, arg=11975122) at eval.c:1091
#84 0x000000000050105f in command_loop () at keyboard.c:1127
#85 recursive_edit_1 () at keyboard.c:754
#86 0x000000000050139a in Frecursive_edit () at keyboard.c:818
#87 0x00000000004171f8 in main (argc=9, argv=<optimized out>) at emacs.c:1699

Lisp Backtrace:
"prin1" (0x24bc5db8)
"byte-compile-output-docform" (0x24bc5f88)
"byte-compile-file-form-defmumble" (0x24bc6130)
0xeffae8 PVEC_COMPILED
0xeffb58 PVEC_COMPILED
0xeffbc8 PVEC_COMPILED
"byte-compile-file-form-defalias" (0x24bc6860)
"byte-compile-file-form" (0x24bc69b8)
"byte-compile-toplevel-file-form" (0x24bc6b18)
0xecaf60 PVEC_COMPILED
0xdd6d38 PVEC_COMPILED
"funcall" (0x24bc6db0)
"byte-compile-from-buffer" (0x24bc7240)
"byte-compile-file" (0x24bc7400)
0xdeb840 PVEC_COMPILED
"funcall" (0x24bc7550)
"batch-byte-compile-file" (0x24bc7990)
"batch-byte-compile" (0x24bc7b80)
"command-line-1" (0x24bc7d00)
"command-line" (0x24bc7ed8)
"normal-top-level" (0x24bc7fb0)

Message #8 received at 11662 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>, 11662 <at> debbugs.gnu.org
Subject: Re: bug#11662: trunk bootstrap segfaults with nonzero MALLOC_PERTURB_
Date: Sat, 09 Jun 2012 19:48:01 -0400

Paul Eggert wrote:

>> Just to let you know that I'm once again seeing temacs segfault
>> when MALLOC_PERTURB_ is nonzero.
[...]
> with backtrace noted below.  This points in the neighborhood of the
> recently-introduced vector allocation code, so I'll CC: this to Dmitry.

That fact that this was first reported in April

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11144

suggests it could be something else.

Message #13 received at 11662 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>, 11662 <at> debbugs.gnu.org
Subject: Re: bug#11662: trunk bootstrap segfaults with nonzero MALLOC_PERTURB_
Date: Sat, 09 Jun 2012 20:41:00 -0700

On 06/09/2012 04:48 PM, Glenn Morris wrote:
> That fact that this was first reported in April
> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11144

That April report looks quite a bit different,
as it doesn't seem to have anything to do with
allocate_vectorlike.

I have verified that if one takes the latest trunk
(bzr 108545), and backs out the recent vector changes
(that is, backs out the changes in bzr 108522 and in
bzr 108520), the bug goes away.  This does not prove
that the bug is due to the vector changes but it is
strongly suggestive.

Message #18 received at 11662 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: Jim Meyering <jim <at> meyering.net>, 11662 <at> debbugs.gnu.org
Subject: Re: FYI, trunk bootstrap segfaults with nonzero MALLOC_PERTURB_
Date: Fri, 21 Sep 2012 14:05:57 -0700

[Message part 1 (text/plain, inline)]

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

[disable_new_vector_alloc.patch (text/x-patch, attachment)]

Message #21 received at 11662 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>, 11662 <at> debbugs.gnu.org
Subject: Re: FYI, trunk bootstrap segfaults with nonzero MALLOC_PERTURB_
Date: Mon, 24 Sep 2012 10:44:15 +0200

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.