Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Daniel Colascione]

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

On 03/21/2014 04:20 PM, Richard M. Stallman wrote:
> ------------------------------------------------------------
> revno: 116836
> revision-id: rms@gnu.org-20140321231626-t531867s02zng3h0
> parent: rms@gnu.org-20140321231032-zpfznmi9r8i6un13
> author: Richard Stallman
> committer: Richard Stallman <rms@gnu.org>
> branch nick: trunk
> timestamp: Fri 2014-03-21 19:16:26 -0400
> message:
>   Avoid GC crashes.
>   
>   * lisp/subr.el (set-transient-map): Clear out function and value
>   of the temporary symbol when we're done with it.
> modified:
>   lisp/ChangeLog                 changelog-20091113204419-o5vbwnq5f7feedwu-1432
>   lisp/subr.el                   subr.el-20091113204419-o5vbwnq5f7feedwu-151
> 

How on earth is that supposed to stop GC crashes?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Glenn Morris]

Daniel Colascione wrote:

> How on earth is that supposed to stop GC crashes?

See http://debbugs.gnu.org/15688 and the various bugs it is merged with,
across which the discussion is split.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Glenn Morris]

Glenn Morris wrote:

> See http://debbugs.gnu.org/15688 and the various bugs it is merged with,
> across which the discussion is [sadly] split.

BTW I now look forward to the rest of the discussion happening on
emacs-devel. :(

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Juanma Barranquero]

On Sat, Mar 22, 2014 at 12:41 AM, Daniel Colascione <dancol@dancol.org> wrote:

> How on earth is that supposed to stop GC crashes?

Look at bugs #15688, #16521, #16278.

IIUC, what Richard means is not that his change fixes the crash, but
that, as no one is apparently able to fix it at this moment, at least
that change makes it stop. A workaround.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Daniel Colascione]

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

On 03/21/2014 04:59 PM, Juanma Barranquero wrote:
> On Sat, Mar 22, 2014 at 12:41 AM, Daniel Colascione <dancol@dancol.org> wrote:
> 
>> How on earth is that supposed to stop GC crashes?
> 
> Look at bugs #15688, #16521, #16278.
> 
> IIUC, what Richard means is not that his change fixes the crash, but
> that, as no one is apparently able to fix it at this moment, at least
> that change makes it stop. A workaround

Thanks. Am I missing something, or is there still no reliable repro? I
feel like gdb's reverse debugging support would be helpful here.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Juanma Barranquero]

On Sat, Mar 22, 2014 at 2:22 AM, Daniel Colascione <dancol@dancol.org> wrote:

> Am I missing something, or is there still no reliable repro?

I think so, but I haven't been following the issue closely.

   J

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Daniel Colascione]

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

On 03/21/2014 06:29 PM, Juanma Barranquero wrote:
> On Sat, Mar 22, 2014 at 2:22 AM, Daniel Colascione <dancol@dancol.org> wrote:
> 
>> Am I missing something, or is there still no reliable repro?
> 
> I think so, but I haven't been following the issue closely.

I see. Until we find the actual GC bug, I'd strongly prefer not
including lisp-level workarounds. Who knows what other problems this bug
causes? How are we supposed to get a good repro for this bug if it hits
even less frequently than it did before Richard's change?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Stefan Monnier]

> I see. Until we find the actual GC bug, I'd strongly prefer not
> including lisp-level workarounds.

FWIW I agree.


        Stefan

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[David Kastrup]

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

>> I see. Until we find the actual GC bug, I'd strongly prefer not
>> including lisp-level workarounds.
>
> FWIW I agree.

There is something to be said to include such workarounds in stable
releases while leaving them off from trunk and possibly unstable
releases (I don't think Emacs has the latter).

-- 
David Kastrup

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I don't think any more progress can be made in debugging this problem
from investigating the situation when the crash occurs.  I've got
all the info from that that I can see how to get.

So there is no point bothering users of the trunk (including me) with
unpredictable and unavoidable crashes.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> So there is no point bothering users of the trunk (including me) with
> unpredictable and unavoidable crashes.

Are there any other people seeing this crash?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Sun, 23 Mar 2014 08:12:00 +0100
> Cc: David Kastrup <dak@gnu.org>, emacs-devel@gnu.org
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> > So there is no point bothering users of the trunk (including me) with
> > unpredictable and unavoidable crashes.
> 
> Are there any other people seeing this crash?

There were several crashes in GC reported since October, at least some
of them might be related.  In bug#16901, Dmitry mentioned some of
them, but there are more.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Daniel Colascione]

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

On 03/23/2014 09:07 AM, Eli Zaretskii wrote:
>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Date: Sun, 23 Mar 2014 08:12:00 +0100
>> Cc: David Kastrup <dak@gnu.org>, emacs-devel@gnu.org
>>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>> So there is no point bothering users of the trunk (including me) with
>>> unpredictable and unavoidable crashes.
>>
>> Are there any other people seeing this crash?
> 
> There were several crashes in GC reported since October, at least some
> of them might be related.  In bug#16901, Dmitry mentioned some of
> them, but there are more.

I thought you found something wrong with gmalloc to explain that one.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Eli Zaretskii]

> Date: Sun, 23 Mar 2014 11:54:31 -0700
> From: Daniel Colascione <dancol@dancol.org>
> CC: dak@gnu.org, rms@gnu.org, emacs-devel@gnu.org
> 
> > There were several crashes in GC reported since October, at least some
> > of them might be related.  In bug#16901, Dmitry mentioned some of
> > them, but there are more.
> 
> I thought you found something wrong with gmalloc to explain that one.

Unfortunately, no.  What I found was that the debugging code in
gmalloc had a bugthat would flag correct code as buggy.  Once those
bugs were fixed, no memory-related problems were ever reported by
gmalloc.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Daniel Colascione]

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

On 03/23/2014 12:09 PM, Eli Zaretskii wrote:
>> Date: Sun, 23 Mar 2014 11:54:31 -0700
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: dak@gnu.org, rms@gnu.org, emacs-devel@gnu.org
>>
>>> There were several crashes in GC reported since October, at least some
>>> of them might be related.  In bug#16901, Dmitry mentioned some of
>>> them, but there are more.
>>
>> I thought you found something wrong with gmalloc to explain that one.
> 
> Unfortunately, no.  What I found was that the debugging code in
> gmalloc had a bugthat would flag correct code as buggy.  Once those
> bugs were fixed, no memory-related problems were ever reported by
> gmalloc.
>

Hrm. Something does seem very wrong then. Why does Richard's always seem
to occur in the same place, though? The rest of these reports seem
arbitrarily distributed. 17068 worries me too: either some logical is
*very* subtly wrong, or there's a bug that scribbles over allocation
metadata (but not other memory?) in such a way as to cause delayed GC
failures.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Eli Zaretskii]

> Date: Sun, 23 Mar 2014 12:53:30 -0700
> From: Daniel Colascione <dancol@dancol.org>
> CC: dak@gnu.org, schwab@linux-m68k.org, rms@gnu.org, emacs-devel@gnu.org
> 
> Hrm. Something does seem very wrong then. Why does Richard's always seem
> to occur in the same place, though?

I don't know.  But note that those reported by Drew also look very
similar only to Drew's own reports.  Not sure what this means.

> The rest of these reports seem arbitrarily distributed.

I see 2 distinct groups reported by Drew: one inside functions called
by balance_intervals_internal, the other in cleanup_vector.

> 17068 worries me too

It's one of the group of several ones, the first being 16288, reported
in December 2013.  Note that there were others, similar to those, the
first one being 15062 from Aug 2013, a month before Richard started
seeing his GC crashes.  So I guess this is some evidence that what
Drew in that group sees is at least somewhat different.

The other group reported by Drew starts with 16414, from Jan 2014.
Note that there was a change in Jan 2014 in intervals.c.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Daniel Colascione]

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

On 03/23/2014 01:10 PM, Eli Zaretskii wrote:
> The other group reported by Drew starts with 16414, from Jan 2014.
> Note that there was a change in Jan 2014 in intervals.c.

16414 predates Dmitry's intervals.c change, though.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 23 Mar 2014 12:53:30 -0700
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: dak@gnu.org, schwab@linux-m68k.org, rms@gnu.org, emacs-devel@gnu.org
>> 
>> Hrm. Something does seem very wrong then. Why does Richard's always seem
>> to occur in the same place, though?
>
> I don't know.  But note that those reported by Drew also look very
> similar only to Drew's own reports.  Not sure what this means.

Is this a failed assertion?  From /etc/DEBUG:

    ** When you are trying to analyze failed assertions or backtraces, it
    is essential to compile Emacs with flags suitable for debugging.
    With GCC 4.8 or later, you can invoke 'make' with CFLAGS="-Og -g3".
    With older GCC or non-GCC compilers, you can use CFLAGS="-O0 -g3".
    With GCC and higher optimization levels such as -O2, the
    -fno-omit-frame-pointer and -fno-crossjumping options are often
    essential.  The latter prevents GCC from using the same abort call for
    all assertions in a given function, rendering the stack backtrace
    useless for identifying the specific failed assertion.

-- 
David Kastrup

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Daniel Colascione <dancol@dancol.org>,  schwab@linux-m68k.org,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Sun, 23 Mar 2014 21:55:44 +0100
> 
> Is this a failed assertion?  From /etc/DEBUG:
> 
>     ** When you are trying to analyze failed assertions or backtraces, it
>     is essential to compile Emacs with flags suitable for debugging.
>     With GCC 4.8 or later, you can invoke 'make' with CFLAGS="-Og -g3".
>     With older GCC or non-GCC compilers, you can use CFLAGS="-O0 -g3".
>     With GCC and higher optimization levels such as -O2, the
>     -fno-omit-frame-pointer and -fno-crossjumping options are often
>     essential.  The latter prevents GCC from using the same abort call for
>     all assertions in a given function, rendering the stack backtrace
>     useless for identifying the specific failed assertion.

That's how Windows snapshots are compiled, indeed.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Daniel Colascione]

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

On 03/23/2014 01:10 PM, Eli Zaretskii wrote:
>> Date: Sun, 23 Mar 2014 12:53:30 -0700
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: dak@gnu.org, schwab@linux-m68k.org, rms@gnu.org, emacs-devel@gnu.org
>>
>> Hrm. Something does seem very wrong then. Why does Richard's always seem
>> to occur in the same place, though?
> 
> I don't know.  But note that those reported by Drew also look very
> similar only to Drew's own reports.  Not sure what this means.
> 
>> The rest of these reports seem arbitrarily distributed.
> 
> I see 2 distinct groups reported by Drew: one inside functions called
> by balance_intervals_internal, the other in cleanup_vector.

How about we add code to automatically run gdb and collect a crash dump?
We can't use MiniDumpWriteDump because gdb can't read Windows minidump
files, and windbg can't understand DWARF symbols.

Or actually, how about integrating Google's Breakpad? It doesn't require
a local gdb, and it comes with a minidump-2-core utility that supposedly
lets gdb debug the resulting dump files.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Eli Zaretskii]

> Date: Sun, 23 Mar 2014 13:59:33 -0700
> From: Daniel Colascione <dancol@dancol.org>
> CC: dak@gnu.org, schwab@linux-m68k.org, rms@gnu.org, emacs-devel@gnu.org
> 
> How about we add code to automatically run gdb and collect a crash dump?

Not sure it would help.  A backtrace, even a full one, usually
immediately raises questions that need a live GDB session and an end
user ready to use it, to answer them.  Without that, a backtrace is
more often than not just a teaser.

> We can't use MiniDumpWriteDump because gdb can't read Windows minidump
> files, and windbg can't understand DWARF symbols.

Right.

> Or actually, how about integrating Google's Breakpad? It doesn't require
> a local gdb, and it comes with a minidump-2-core utility that supposedly
> lets gdb debug the resulting dump files.

According to this:

  https://code.google.com/p/google-breakpad/issues/detail?id=436

it doesn't support GCC-produced DWARF2 debug info, unless you apply
patches both to Breakpad and to Binutils.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I investigated further and got additional information.  This time, at
least, the vector had not been freed; it was PVEC_NORMAL_VECTOR.  The
crash is due to a junk entry in the vector itself!

It happened despite my workaround, which apparently is not preventing
the problem.  Though it had seemed to do so for a while.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Daniel Colascione]

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

On 03/25/2014 05:42 AM, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
> I investigated further and got additional information.  This time, at
> least, the vector had not been freed; it was PVEC_NORMAL_VECTOR.  The
> crash is due to a junk entry in the vector itself!
> 
> It happened despite my workaround, which apparently is not preventing
> the problem.  Though it had seemed to do so for a while.
> 

Did you manage to collect a core dump?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Did you manage to collect a core dump?

No, I did not think of that when pr crashed.  I will try to remember
next time.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Daniel Colascione]

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

On 03/25/2014 03:41 PM, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>     Did you manage to collect a core dump?
> 
> No, I did not think of that when pr crashed.  I will try to remember
> next time.

Thanks. Can you also please revert your subr.el change? It doesn't
prevent crashes, and I'm worried it may be shifting the problem elsewhere.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Dmitry Antipov]

On 03/25/2014 04:42 PM, Richard Stallman wrote:

> It happened despite my workaround, which apparently is not preventing
> the problem.  Though it had seemed to do so for a while.

Can you upload your binary (and core, if any) somewhere?

IIUC gNewSense still uses gcc-4.4; is it possible to try a never version of gcc?
(gcc < 4.7.2 is known to have a few MIPS-related issues, as observed by the kernel
developers; see http://www.linux-mips.org/wiki/GCC#GCC_4.7.1_and_older_code_generation_bug).

Dmitry

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Eli Zaretskii]

> Date: Tue, 25 Mar 2014 19:24:16 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> Cc: emacs-devel@gnu.org
> 
> IIUC gNewSense still uses gcc-4.4; is it possible to try a never version of gcc?
> (gcc < 4.7.2 is known to have a few MIPS-related issues, as observed by the kernel
> developers; see http://www.linux-mips.org/wiki/GCC#GCC_4.7.1_and_older_code_generation_bug).

I very much doubt that a compiler bug could explain this.  The bugs
referenced above are all in optimized code, while Richard compiles
with -O0, AFAIR.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    IIUC gNewSense still uses gcc-4.4; is it possible to try a never version of gcc?

To get and install a newer GCC then rebuild Emacs is a lot of work.
I can't promise to do this.

I always compile with -O0 to make debugging easier.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Eli Zaretskii]

> Date: Tue, 25 Mar 2014 08:42:33 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: dancol@dancol.org, dak@gnu.org, schwab@linux-m68k.org,
> 	emacs-devel@gnu.org
> 
> I investigated further and got additional information.  This time, at
> least, the vector had not been freed; it was PVEC_NORMAL_VECTOR.  The
> crash is due to a junk entry in the vector itself!

What kind of junk entry?  Maybe post it here, someone could have an
idea about where could it come from.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    What kind of junk entry?

I never got to find that out.  I was printing elements one by one
with pr, and on the bad one pr crashed and I could not recover.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Eli Zaretskii]

> Date: Tue, 25 Mar 2014 18:39:40 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: dancol@dancol.org, dak@gnu.org, schwab@linux-m68k.org,
> 	emacs-devel@gnu.org
> 
>     What kind of junk entry?
> 
> I never got to find that out.  I was printing elements one by one
> with pr, and on the bad one pr crashed and I could not recover.

That's why etc/DEBUG advises not to use 'pr' in these situations.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > I never got to find that out.  I was printing elements one by one
    > with pr, and on the bad one pr crashed and I could not recover.

    That's why etc/DEBUG advises not to use 'pr' in these situations.

Alas, there were so many elements.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Eli Zaretskii]

> Date: Wed, 26 Mar 2014 09:46:40 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: dancol@dancol.org, dak@gnu.org, schwab@linux-m68k.org,
> 	emacs-devel@gnu.org
> 
>     > I never got to find that out.  I was printing elements one by one
>     > with pr, and on the bad one pr crashed and I could not recover.
> 
>     That's why etc/DEBUG advises not to use 'pr' in these situations.
> 
> Alas, there were so many elements.

Maybe we should have a segfault-safe 'pr', using valid_pointer_p?

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Ivan Andrus]

On Mar 23, 2014, at 1:12 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:

> Richard Stallman <rms@gnu.org> writes:
> 
>> So there is no point bothering users of the trunk (including me) with
>> unpredictable and unavoidable crashes.
> 
> Are there any other people seeing this crash?

I think I’ve experienced the same crash.  I noticed the backtrace was in GC a few times.  But I can’t reproduce the problem reliably (or really at all anymore).  There as a time a few months ago when it was much easier for me to reproduce it.  It would happen after an hour or so of use.  It’s much less common now—I just had an uptime of 13 days.

I’m on OS X 10.9.2 using the NS version that I build periodically from trunk.  I experienced the problem more when I was on 10.8.

-Ivan

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Eli Zaretskii]

> From: Ivan Andrus <darthandrus@gmail.com>
> Date: Sun, 23 Mar 2014 23:50:21 -0600
> Cc: David Kastrup <dak@gnu.org>, rms@gnu.org, emacs-devel@gnu.org
> 
> On Mar 23, 2014, at 1:12 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> 
> > Richard Stallman <rms@gnu.org> writes:
> > 
> >> So there is no point bothering users of the trunk (including me) with
> >> unpredictable and unavoidable crashes.
> > 
> > Are there any other people seeing this crash?
> 
> I think I’ve experienced the same crash.  I noticed the backtrace was in GC a few times.  But I can’t reproduce the problem reliably (or really at all anymore).  There as a time a few months ago when it was much easier for me to reproduce it.  It would happen after an hour or so of use.  It’s much less common now—I just had an uptime of 13 days.
> 
> I’m on OS X 10.9.2 using the NS version that I build periodically from trunk.  I experienced the problem more when I was on 10.8.

Do you have the backtraces somewhere that you can post?  If not,
please do so the next time you see such problems.  It is important for
us to know whether your GC crashes are similar to those reported by
others.

Thanks.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Ivan Andrus]

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

On Mar 24, 2014, at 10:51 AM, Eli Zaretskii <eliz@gnu.org> wrote:

From: Ivan Andrus <darthandrus@gmail.com>
Date: Sun, 23 Mar 2014 23:50:21 -0600
Cc: David Kastrup <dak@gnu.org>, rms@gnu.org, emacs-devel@gnu.org

On Mar 23, 2014, at 1:12 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:

Richard Stallman <rms@gnu.org> writes:

So there is no point bothering users of the trunk (including me) with
unpredictable and unavoidable crashes.


Are there any other people seeing this crash?


I think I've experienced the same crash.  I noticed the backtrace was in GC
a few times.  But I can't reproduce the problem reliably (or really at all
anymore).  There as a time a few months ago when it was much easier for me
to reproduce it.  It would happen after an hour or so of use.  It's much
less common now--I just had an uptime of 13 days.

I'm on OS X 10.9.2 using the NS version that I build periodically from
trunk.  I experienced the problem more when I was on 10.8.


Do you have the backtraces somewhere that you can post?  If not,
please do so the next time you see such problems.  It is important for
us to know whether your GC crashes are similar to those reported by
others.


I can't find any that I may have saved.  I'll make sure to keep any that I
get in the future.

Thanks,
Ivan

[-- Attachment #2: Type: text/html, Size: 2093 bytes --]

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > I see. Until we find the actual GC bug, I'd strongly prefer not
    > including lisp-level workarounds.

    FWIW I agree.

I will include it in the code I run.  I am tired of getting these
crashes, and it isn't useful any more since I can't do any more
debugging them.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Daniel Colascione]

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

On 03/22/2014 04:57 PM, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>     > I see. Until we find the actual GC bug, I'd strongly prefer not
>     > including lisp-level workarounds.
> 
>     FWIW I agree.
> 
> I will include it in the code I run.  I am tired of getting these
> crashes, and it isn't useful any more since I can't do any more
> debugging them.

You can do what you like in your copy of Emacs. There's no need to push
that to the tree, however.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Eli Zaretskii]

> Date: Sat, 22 Mar 2014 17:14:11 -0700
> From: Daniel Colascione <dancol@dancol.org>
> Cc: lekktu@gmail.com, emacs-devel@gnu.org
> 
> > I will include it in the code I run.  I am tired of getting these
> > crashes, and it isn't useful any more since I can't do any more
> > debugging them.
> 
> You can do what you like in your copy of Emacs. There's no need to push
> that to the tree, however.

Let's do that for every bug we find, then, shall we?

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 22 Mar 2014 17:14:11 -0700
>> From: Daniel Colascione <dancol@dancol.org>
>> Cc: lekktu@gmail.com, emacs-devel@gnu.org
>> 
>> > I will include it in the code I run.  I am tired of getting these
>> > crashes, and it isn't useful any more since I can't do any more
>> > debugging them.
>> 
>> You can do what you like in your copy of Emacs. There's no need to push
>> that to the tree, however.
>
> Let's do that for every bug we find, then, shall we?

Until we find a proper fix, yes.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Daniel Colascione <dancol@dancol.org>,  lekktu@gmail.com,  emacs-devel@gnu.org,  rms@gnu.org,  monnier@iro.umontreal.ca
> Date: Sun, 23 Mar 2014 08:05:45 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Sat, 22 Mar 2014 17:14:11 -0700
> >> From: Daniel Colascione <dancol@dancol.org>
> >> Cc: lekktu@gmail.com, emacs-devel@gnu.org
> >> 
> >> > I will include it in the code I run.  I am tired of getting these
> >> > crashes, and it isn't useful any more since I can't do any more
> >> > debugging them.
> >> 
> >> You can do what you like in your copy of Emacs. There's no need to push
> >> that to the tree, however.
> >
> > Let's do that for every bug we find, then, shall we?
> 
> Until we find a proper fix, yes.

Which in this case means never, because no one is working on that.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Which in this case means never

No.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > I will include it in the code I run.  I am tired of getting these
    > crashes, and it isn't useful any more since I can't do any more
    > debugging them.

    You can do what you like in your copy of Emacs. There's no need to push
    that to the tree, however.

You're trying to apply a principle that is applicable to bugs that
surely have a recipe but we don't know what it is: don't paper it
over, so that people will encounter it and someone will find a recipe.

That's not universal; this is not that kind of bug.  I suspect it
occurs because one GC makes a mistake that causes subsequent data
corruption that causes the next GC to crash.

It's possible the bug affects only Mips machines, and it's possible I
am the only Yeeloong user on this list, but other Yeeloong users do
use Emacs.  It won't help us to cause them to get unpredictable GC
crashes.  If one of them decides to make a little attempt to
investigate, he will only tell us the beginning of what we already
know.  Most users won't know how to investigate it as far as I did.

The work needed to find this bug is a different kind.

We should install the workaround.  That won't stop us from working on
the GCC bug, when we want to.  It will however spare some users Emacs
crashes in the meantime.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Thanks. Am I missing something, or is there still no reliable repro? I
    feel like gdb's reverse debugging support would be helpful here.

I don't know how much time passes between the vector gets freed
and when the symbol gets marked.  I suspect it is the time
between one GC and the next, which would be millions of instructions.
Can reverse execution handle that?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Rüdiger Sonderfeld]

On Saturday 22 March 2014 19:57:02 Richard Stallman wrote:
>     Thanks. Am I missing something, or is there still no reliable repro? I
>     feel like gdb's reverse debugging support would be helpful here.
> 
> I don't know how much time passes between the vector gets freed
> and when the symbol gets marked.  I suspect it is the time
> between one GC and the next, which would be millions of instructions.
> Can reverse execution handle that?

Maybe Mozilla's new rr project could help here

* http://robert.ocallahan.org/2014/03/introducing-rr.html
* http://rr-project.org/

It records the execution and allows replays

> rr aspires to be your primary debugging tool, replacing — well, enhancing —
> gdb. You record a failure once, then debug the recording,
> deterministically, as many times as you want. Every time the same execution
> is replayed.

Regards,
Rüdiger

Re: [Emacs-diffs] trunk r116836: Avoid GC crashes.

[Eli Zaretskii]

> From: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
> Date: Wed, 26 Mar 2014 15:42:03 +0100
> Cc: lekktu@gmail.com, Daniel Colascione <dancol@dancol.org>
> 
> On Saturday 22 March 2014 19:57:02 Richard Stallman wrote:
> >     Thanks. Am I missing something, or is there still no reliable repro? I
> >     feel like gdb's reverse debugging support would be helpful here.
> > 
> > I don't know how much time passes between the vector gets freed
> > and when the symbol gets marked.  I suspect it is the time
> > between one GC and the next, which would be millions of instructions.
> > Can reverse execution handle that?
> 
> Maybe Mozilla's new rr project could help here
> 
> * http://robert.ocallahan.org/2014/03/introducing-rr.html
> * http://rr-project.org/
> 
> It records the execution and allows replays

It's x86 specific, so will most probably not work on Richard's
machine.

gNewSense QEMU setup [Was: Re: [Emacs-diffs] trunk r116836: Avoid GC crashes]

[Dmitry Antipov]

Now I have gNewSense 3.0 MIPS QEMU setup. So if there is a recipe to reproduce
this crash, I would like to have a chance to try; also if someone wishes to join
me in attempt to pursue this annoying issue, I can share my stuff and experience
in running (almost?) RMS-compatible system on top of x86 GNU/Linux.

Dmitry

Re: gNewSense QEMU setup [Was: Re: [Emacs-diffs] trunk r116836: Avoid GC crashes]

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Now I have gNewSense 3.0 MIPS QEMU setup. So if there is a recipe
    to reproduce this crash, I would like to have a chance to try;

Alas, I have not been able to correlate it with any specific editing
activities.  However, using commands that call set-transient-map
would make it more likely.  They include C-u and indent-rigidly
and C-x z.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: gNewSense QEMU setup [Was: Re: [Emacs-diffs] trunk r116836: Avoid GC crashes]

[Daniel Colascione]

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

On 03/28/2014 04:17 PM, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>     Now I have gNewSense 3.0 MIPS QEMU setup. So if there is a recipe
>     to reproduce this crash, I would like to have a chance to try;
> 
> Alas, I have not been able to correlate it with any specific editing
> activities.  However, using commands that call set-transient-map
> would make it more likely.  They include C-u and indent-rigidly
> and C-x z.

I'm concerned that your change to subr.el might be moving the GC bug
elsewhere. Before your change, we had a semi-reliable repro. Now, we
have no idea where the bug is going to pop up. Would you please revert
your subr.el change?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: gNewSense QEMU setup [Was: Re: [Emacs-diffs] trunk r116836: Avoid GC crashes]

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    I'm concerned that your change to subr.el might be moving the GC bug
    elsewhere. Before your change, we had a semi-reliable repro.

Not really.  If I edited for a week, it was likely to happen.

But I will take out the work-around in case it does something.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.