Re: Changes that should go into version 24.4

[Eli Zaretskii]

> Date: Sat, 22 Mar 2014 01:50:23 -0700
> From: Daniel Colascione <address@hidden>
> CC: address@hidden, address@hidden
> 
> > Since (evidently) no one is actively works on fixing that bug,
> 
> It's not that nobody's working on it --- it's that there's not enough
> information to make progress. The crash happens sporadically.

Working on a bug includes adding debugging code that would help
collecting the missing information.  AFAICS, no one is doing that,
either.

> > I see
> > no reasons to punish people who run the trunk codebase by imposing on
> > them random crashes they cannot recover from.  As long as the bug
> > remains open, we didn't forget about it, and will fix it eventually;
> > in the meantime, let users have one less reason for crashes.
> 
> If this were a normal bug, I'd agree completely --- but this bug is one
> we can't reproduce. (I've tried.) The more people see this problem, the
> greater the chance we'll get the information we need to actually fix its
> underlying cause.

It is unreasonable to use others as guinea pigs in such cases, IMO.

Also, we have already several other reports about GC-related crashes,
see the list in bug #16901
(http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16901#32).  Not sure if
those are related, but if they aren't, how can we explain that only
Richard experiences these problems?

Perhaps searching the debbugs reports about any crashes in GC will
reveal other potential candidates that are related to the same bug?

> Without a reliable repro, what alternative would you suggest?

Richard reported that the crashes started when he updated his branch
not later than Sep 22, and that his previous update was around Aug 18.
We could start by scrutinizing relevant changes between Aug 18 and Sep
22.

In http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15688#107, Stefan
described some insight on the problem, and Richard suggested that
someone writes debugging code to detect the situation that apparently
is a precursor to the crash.  No one wrote such a code, AFAIK; perhaps
we should.  (I don't understand what Stefan said enough to do this,
but maybe someone else does.)

I also agree that having a core file from the crash might help,
although we shouldn't have our expectations about that too high, since
such core files are only good for determining which Lisp object caused
it, and Richard already found out and described that.  The efforts now
should be to understand how does that object get corrupted, which is
not something a core file from GC would normally help with.