Re: GOP-PROP 8: issue priorities (probable decision)

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Sat, Aug 13, 2011 at 07:12:53AM +0200, David Kastrup wrote:
>> Keith OHara <address@hidden> writes:
>> 
>> > Issue 1809 is an interesting test of this policy.  `make test`
>> > sometimes crashes for some programmers, making it very hard for them
>> > to contribute, but it crashes in the Guile garbage collection, so we
>> > might be powerless to resolve the issue.
>> 
>> It crashes because the internal garbage collector data structures have
>> been clobbered.  Which is likely due to some Lilypond code problem (like
>> data available too early for collection).  So it is likely that we are
>> not "powerless to resolve the issue", but since the crash is happening
>> at a point rather remote from the likely bug and is quite sensitive to
>> the memory layout of the code, it is really hard to track down.
>
> If it's at all relevant, we haven't heard any complaints about
> thsi before a month or two ago.  Without a reliable test, this
> doesn't really help in narrowing down the scope of the problem --
> but I do believe that it's due to (or at least, exacerbated by) a
> relatively recent lilypond code change.
>
> I think we can avoid the horns of the dilemma, though:
> - if it crashes regularly, (safe) contribution is impossible.  But
>   then we have a reliable (or at least reliable-ish) test case.
> - if it crashes very infrequently, (safe) contribution is a pain,
>   but not impossible.
>
> Given the frequency I've heard about, I'd rank this as
> type-Maintainability, rather than type-Critical.  With a note that
> if anybody can reproduce it with a command-line more than 30% of
> the time, we'll bump it up to type-Critical.

I don't get regtests through 100% of the time with the normal
compilation options.  I am using more debugging-friendly options right
now (particularly -fkeep-inline-functions), and the bug does not make
itself noticeable.  I've spent half a week on trying to track this down
or pin it to particular code.  I really can't invest more work in this
at the time.  In particular work without predictable progress.

So maybe we need to improve our toolset for memory leaks.  Like having
an option to trigger garbage collection at _every_ allocation, and
clobbering all memory that is supposedly free.

Which is mostly something one would want from guile, so the question is
whether one can ask the guile people for a debugging tool like that.

Giving the somewhat unpredictable behavior of the stack-scanning
conservative garbage collector, it would seem like an important tool in
the debugging toolbox.

-- 
David Kastrup