Graham Percival <[email protected]> writes: > On Sat, Aug 13, 2011 at 07:12:53AM +0200, David Kastrup wrote: >> Keith OHara <[email protected]> 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
