Re: lilypond consistent crash

[Trevor Bača]

On 9/23/07, Adam James Wilson <address@hidden> wrote:
> Hi folks,
>
> I'm pretty frustrrated at the moment - wondering if anyone has
> exeperienced a similar problem.
>
> I unfortunately don't have a small snippet to describe the problem,
> because it seems to arise from volume/complexity. . .
>
> Here's what I'm doing:
>
> I'm using a global "invisible" voice at 3/8 in all staves of my score.
>  I'm using proportional notation, strict stretching and spacing, and
> force a line break at every 4 measures in the global voice
>
> I have several actual voices in different staves all barred at
> different tempos, which are constantly changing: for example, 71 bars
> of 3/8 in the space of 49 bars of the global voice.  I'm using
> compressMusic to accomplish this.
>
> Timing, barline engraver, and rehearsal marks are all on the staff
> context, since each staff has a different tempo.  At points some of
> the barlines sync up, and then move off again.
>
> Since my piece has reached a certain size, lilypond will chug away at
> the score and then simply stop, without writing .ps or .pdf files.  I
> tried with both mac os X 10.4 (PPC) and windows XP versions of
> 2.11.32.  Memory keeps getting consumed - up to 387MB in one trial -
> and the console prints about a zillion of the following warnings
> before quitting:
>
> programming error: minimise_least_squares ():  Nothing to minimise
> This means that vertical spacing is triggered
> before line breaking
> continuing, cross fingers
>
> I've sort of committed to Lily as a medium for what I'm doing - no
> other software seems to be able to do multi-tempo proprtional
> notation; however, I'm only a few minutes into the piece and have
> encountered this rendering roadblock.
>
> Rendering the piece in chunks will not work (unless someone knows a
> trick) because so many bars are breaking at a line break (this is what
> I want - horizontal consistency in time as well as relative temporal
> consistency between parts) - there are almost no places where a page
> finishes with all parts together.
>
> I'm wondering if this has anything to do with the timing bug I
> discovered whereby compressMusic doesn't compress capital-R rests
> properly without the addition of a funky \time ratio; perhaps there
> are other hidden problems with compressMusic?
>
> Any help would be greatly appreciated - I'm on a deadline (end of
> October) to finish this piece; if a fix requires sponsorship I'm
> willing to kick in.


Hi Adam,

I was just taking a break from partitioning my current inputfile due
to this same bug whenI clicked over and saw your mail.

Some time ago -- unfortunately I haven't been able to pinpoint the
exact release -- a filesize-related rendering problem did indeed enter
the 2.11 development releases. I opened Google #433
(http://code.google.com/p/lilypond/issues/detail?id=433) and both Joe
and Nicolas jumped to help.

I think Joe found that the problem difficult to reproduce except under
OS X Intel, so Nicolas very graciously ran my offending file (under OS
X Intel) and was indeed able to reproduce the same segementation
fault. However, it seems that what's needed is to run one of the
offending files under gdp with a version of lily that still has all
the debug messages compiled in. Nicolas got very close; I'm further
away because I don't have the chops to build an unstripped version
from source at the moment.

So I'm pretty sure that's where the issue lies. The gurus know about
the problem but are very busy  and so we may still be a bit away from
the fix. FWIW, I think we're not the only ones experiencing the
problem; Aurélien mailed me off the list to report what appears to be
the same problem and then added a comment to #433 afterwards.

So, what to do as a workaround in the meantime?

I've just now partitioned the trio that I'm working on (which likewise
has an October deadline) into three separate inputfiles. And that
seems to be working. I can get about 100 measures of extremely dense
music per file before the segementation fault shows up ... and the
piece is 230 measures. It took about a day and half to get the
partitioning right because I had to manually sever spanners and
octavation commands and insert dummy \bar "" breaks to satisfy
line-breaking etc on either side of the breaks in the file. But it did
indeed work.

So is there a way we can get your inputfile broken into
non-segfault-inducing chunks as a workaround? My guess is that your
line-breaks fall neatly at barlines in *one* of the staves in your
score but at extremely complex midmeasure metrical points in the other
staves of your score; is this the problem?

If so, you should be able to insert dummy bars with \bar "" at
precisely the points where you need ilne-breaking to occur in the
"messy staves". Some incantation like s1 * 12/59 \bar "" should work
to, for example, position a breakable point at 12/59ths of a whole
note into the middle of one of the "messy" measures. Does this help?

There *should* be a way to partition your inputfile and get your
through the transition period. If you can't get it to work, cut out a
snippet that shows a place where you'd like to sever the file (but are
unable to), send back to me (cc the list) and I'll help you get it.
Also, keep your chin up -- Orm (Finnendahl), Víctor (Adán) and I have
all used the proportional package with remarkably successful results
that would be damn near impossible in the other notation packages;
your scores look like they fall into the same category and I strongly
encourage you to work through the current trouble spot.

Gurus - everyone is clearly busy (and I get the feeling that the
limiting factor right now is time not money), but I'll go ahead and
second Adam's offer for sponsorship to move past the current segfault
bug.

Also, I've switched this thread over to -devel and added the folks I
mentioned up above.



-- 
Trevor Bača
address@hidden