bootstrap w/gcc-4.8.0 + nonzero MALLOC_PERTURB_ -> ./temacs segfault

bootstrap w/gcc-4.8.0 + nonzero MALLOC_PERTURB_ -> ./temacs segfault

[Jim Meyering]

Just a heads-up, since release is so near:

    gcc-4.8.0 vs emacs+MALLOC_PERTURB_ = ./temacs segfault
    http://debbugs.gnu.org/11144

It would be a shame if gcc-4.8.0 (even test a release) were to
fail to bootstrap emacs with MALLOC_PERTURB_ set to nonzero.

Re: bootstrap w/gcc-4.8.0 + nonzero MALLOC_PERTURB_ -> ./temacs segfault

[Jim Meyering]

Jim Meyering wrote:
> Just a heads-up, since release is so near:
>
>     gcc-4.8.0 vs emacs+MALLOC_PERTURB_ = ./temacs segfault
>     http://debbugs.gnu.org/11144
>
> It would be a shame if gcc-4.8.0 (even test a release) were to
> fail to bootstrap emacs with MALLOC_PERTURB_ set to nonzero.

This seems to have been fixed, since with the latest from gcc/svn,
  git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186106 138bc75d-0d04-0410-961f-82ee72b054a4
I can now bootstrap the latest emacs.

bug#11144: bootstrap w/gcc-4.8.0 + nonzero MALLOC_PERTURB_ -> ./temacs segfault

[Jim Meyering]

Jim Meyering wrote:
> Jim Meyering wrote:
>> Just a heads-up, since release is so near:
>>
>>     gcc-4.8.0 vs emacs+MALLOC_PERTURB_ = ./temacs segfault
>>     http://debbugs.gnu.org/11144
>>
>> It would be a shame if gcc-4.8.0 (even test a release) were to
>> fail to bootstrap emacs with MALLOC_PERTURB_ set to nonzero.
>
> This seems to have been fixed, since with the latest from gcc/svn,
>   git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186106
> 138bc75d-0d04-0410-961f-82ee72b054a4
> I can now bootstrap the latest emacs.

This has struck again, now using gcc version 4.8.0 20120406
I've reopened the bug.

Re: bootstrap w/gcc-4.8.0 + nonzero MALLOC_PERTURB_ -> ./temacs segfault

[Jim Meyering]

Jim Meyering wrote:
> Jim Meyering wrote:
>> Just a heads-up, since release is so near:
>>
>>     gcc-4.8.0 vs emacs+MALLOC_PERTURB_ = ./temacs segfault
>>     http://debbugs.gnu.org/11144
>>
>> It would be a shame if gcc-4.8.0 (even test a release) were to
>> fail to bootstrap emacs with MALLOC_PERTURB_ set to nonzero.
>
> This seems to have been fixed, since with the latest from gcc/svn,
>   git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186106
> 138bc75d-0d04-0410-961f-82ee72b054a4
> I can now bootstrap the latest emacs.

This has struck again, now using gcc version 4.8.0 20120406
I've reopened the bug.

bug#11144: bootstrap w/gcc-4.8.0 + nonzero MALLOC_PERTURB_ -> ./temacs segfault

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Date: Tue, 10 Apr 2012 11:13:13 +0200
> Cc: 11144@debbugs.gnu.org
> 
> Jim Meyering wrote:
> > Jim Meyering wrote:
> >> Just a heads-up, since release is so near:
> >>
> >>     gcc-4.8.0 vs emacs+MALLOC_PERTURB_ = ./temacs segfault
> >>     http://debbugs.gnu.org/11144
> >>
> >> It would be a shame if gcc-4.8.0 (even test a release) were to
> >> fail to bootstrap emacs with MALLOC_PERTURB_ set to nonzero.
> >
> > This seems to have been fixed, since with the latest from gcc/svn,
> >   git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186106
> > 138bc75d-0d04-0410-961f-82ee72b054a4
> > I can now bootstrap the latest emacs.
> 
> This has struck again, now using gcc version 4.8.0 20120406
> I've reopened the bug.

Why should we consider this an Emacs bug?  Is there any evidence that
it's not a GCC bug, especially since it is coming and going depending
on GCC commits, and that you are using unreleased version of GCC?

P.S.  Please don't CC emacs-devel on bug reports, it causes problems
with the bug tracker, which sometimes creates bogus new bugs.

bug#11144: bootstrap w/gcc-4.8.0 + nonzero MALLOC_PERTURB_ -> ./temacs segfault

[Jim Meyering]

Eli Zaretskii wrote:
>> From: Jim Meyering <jim@meyering.net>
>> Date: Tue, 10 Apr 2012 11:13:13 +0200
>> Cc: 11144@debbugs.gnu.org
>>
>> Jim Meyering wrote:
>> > Jim Meyering wrote:
>> >> Just a heads-up, since release is so near:
>> >>
>> >>     gcc-4.8.0 vs emacs+MALLOC_PERTURB_ = ./temacs segfault
>> >>     http://debbugs.gnu.org/11144
>> >>
>> >> It would be a shame if gcc-4.8.0 (even test a release) were to
>> >> fail to bootstrap emacs with MALLOC_PERTURB_ set to nonzero.
>> >
>> > This seems to have been fixed, since with the latest from gcc/svn,
>> >   git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186106
>> > 138bc75d-0d04-0410-961f-82ee72b054a4
>> > I can now bootstrap the latest emacs.
>>
>> This has struck again, now using gcc version 4.8.0 20120406
>> I've reopened the bug.
>
> Why should we consider this an Emacs bug?  Is there any evidence that
> it's not a GCC bug, especially since it is coming and going depending
> on GCC commits, and that you are using unreleased version of GCC?

I do not know enough about this to claim it is due to a bug in gcc or in
emacs.  However, note that this report shows a probable use of freed memory
in temacs, and that generally implicates the application, not the compiler.

One additional data point: I've just built today's gcc version 4.8.0 20120410,
and have used it to bootstrap emacs(trunk) four times with no such failure.

bug#11144: bootstrap w/gcc-4.8.0 + nonzero MALLOC_PERTURB_ -> ./temacs segfault

[Paul Eggert]

On 04/10/2012 02:13 AM, Jim Meyering wrote:

> This has struck again, now using gcc version 4.8.0 20120406
> I've reopened the bug.

This is in an area of Emacs code that is sensitive to
minor details in how the C compiler works, and it's
quite possible that the bug is in Emacs, not in GCC.
Certainly I've seen similar tracebacks which came
from Emacs bugs.

If you're bisecting, you might want to look at Emacs
trunk bzr 107789, which I committed three days ago, and
which affects this part of the code.  I don't offhand
see why it would cause the problem (though perhaps
it might *fix* the problem :-).

Re: bootstrap w/gcc-4.8.0 + nonzero MALLOC_PERTURB_ -> ./temacs segfault

[Jim Meyering]

Jim Meyering wrote:

> Jim Meyering wrote:
>> Jim Meyering wrote:
>>> Just a heads-up, since release is so near:
>>>
>>>     gcc-4.8.0 vs emacs+MALLOC_PERTURB_ = ./temacs segfault
>>>     http://debbugs.gnu.org/11144
>>>
>>> It would be a shame if gcc-4.8.0 (even test a release) were to
>>> fail to bootstrap emacs with MALLOC_PERTURB_ set to nonzero.
>>
>> This seems to have been fixed, since with the latest from gcc/svn,
>>   git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186106
>> 138bc75d-0d04-0410-961f-82ee72b054a4
>> I can now bootstrap the latest emacs.
>
> This has struck again, now using gcc version 4.8.0 20120406
> I've reopened the bug.

While I filed in a new bug, the patch in bug#11288 may well
solve the above, too:

    avoid buffer overrun in display code
    http://bugs.gnu.org/11288

Re: bootstrap w/gcc-4.8.0 + nonzero MALLOC_PERTURB_ -> ./temacs segfault

[Eli Zaretskii]

> From: Jim Meyering <jim@meyering.net>
> Date: Fri, 20 Apr 2012 13:54:16 +0200
> 
> Jim Meyering wrote:
> 
> > Jim Meyering wrote:
> >> Jim Meyering wrote:
> >>> Just a heads-up, since release is so near:
> >>>
> >>>     gcc-4.8.0 vs emacs+MALLOC_PERTURB_ = ./temacs segfault
> >>>     http://debbugs.gnu.org/11144
> >>>
> >>> It would be a shame if gcc-4.8.0 (even test a release) were to
> >>> fail to bootstrap emacs with MALLOC_PERTURB_ set to nonzero.
> >>
> >> This seems to have been fixed, since with the latest from gcc/svn,
> >>   git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186106
> >> 138bc75d-0d04-0410-961f-82ee72b054a4
> >> I can now bootstrap the latest emacs.
> >
> > This has struck again, now using gcc version 4.8.0 20120406
> > I've reopened the bug.
> 
> While I filed in a new bug, the patch in bug#11288 may well
> solve the above, too:
> 
>     avoid buffer overrun in display code
>     http://bugs.gnu.org/11288

Please see if revision 107873 on the emacs-24 branch, which should
solve the overrun, solves also the bootstrap problem.  (Personally, I
doubt that, because display code is not invoked during bootstrap.  But
then who knows?)

Re: bootstrap w/gcc-4.8.0 + nonzero MALLOC_PERTURB_ -> ./temacs segfault

[Jim Meyering]

Eli Zaretskii wrote:
>> From: Jim Meyering <jim@meyering.net>
>> Date: Fri, 20 Apr 2012 13:54:16 +0200
>>
>> Jim Meyering wrote:
>>
>> > Jim Meyering wrote:
>> >> Jim Meyering wrote:
>> >>> Just a heads-up, since release is so near:
>> >>>
>> >>>     gcc-4.8.0 vs emacs+MALLOC_PERTURB_ = ./temacs segfault
>> >>>     http://debbugs.gnu.org/11144
>> >>>
>> >>> It would be a shame if gcc-4.8.0 (even test a release) were to
>> >>> fail to bootstrap emacs with MALLOC_PERTURB_ set to nonzero.
>> >>
>> >> This seems to have been fixed, since with the latest from gcc/svn,
>> >>   git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186106
>> >> 138bc75d-0d04-0410-961f-82ee72b054a4
>> >> I can now bootstrap the latest emacs.
>> >
>> > This has struck again, now using gcc version 4.8.0 20120406
>> > I've reopened the bug.
>>
>> While I filed in a new bug, the patch in bug#11288 may well
>> solve the above, too:
>>
>>     avoid buffer overrun in display code
>>     http://bugs.gnu.org/11288
>
> Please see if revision 107873 on the emacs-24 branch, which should
> solve the overrun, solves also the bootstrap problem.  (Personally, I
> doubt that, because display code is not invoked during bootstrap.  But
> then who knows?)

I don't have a reliable reproducer for that one.
I typically bootstrap the latest emacs using the latest gcc, once or
twice a day.  If I go a couple weeks without hitting the above bug,
I'll start to wonder if it's been resolved.

Today it has not been triggered, neither before nor after your change.
The last time I saw it was when building on April 17th.

bug#11144: bootstrap w/gcc-4.8.0 + nonzero MALLOC_PERTURB_ -> ./temacs segfault

[Jim Meyering]

Jim Meyering wrote:
> Just a heads-up, since release is so near:
>
>     gcc-4.8.0 vs emacs+MALLOC_PERTURB_ = ./temacs segfault
>     http://debbugs.gnu.org/11144
>
> It would be a shame if gcc-4.8.0 (even test a release) were to
> fail to bootstrap emacs with MALLOC_PERTURB_ set to nonzero.

This seems to have been fixed, since with the latest from gcc/svn,
  git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@186106 138bc75d-0d04-0410-961f-82ee72b054a4
I can now bootstrap the latest emacs.