Re: segfault in grob.cc

[Mats Bengtsson]

> > I appended 'ulimit -a' to the os.system command so I could see what my
> > resources were.  It turns out that the stack size is <2K, which is an odd
> > number (I don't know where it comes from)  because from the shell it
> > reports 8K.

I've experienced similar problems with a large score, so you're
not alone. I never thought of checking ulimit, but you're completely
right, within os.system(...) the stack size is 2040 instead of the
default 8192 when I run outside Python. I use the standard Python
package included in Debian 2.2. My guess is that the Python program
changes the max stack size of its own process and this setting is
then inherited when you call system(). I haven't checked the source
code, though. I can also confirm that it helps to increase the 
limit. Great, this problem has been bugging me for quite some time.

> > What is the largest score that has been processed with lilypond so
> > far?  Mine is 830 measures of a score with 12 parts.  Not quite a
> > Mahler symphony, but pretty big.
> 
> That's indeed pretty big.  The largest score that I have actually seen
> typeset, is the Ouverture Coriolan (now in Mutopia).  It has 314
> measures and 12 staffs, or 19 parts.  It needed about 110Mb of memory
> to process.  How much memory does your machine have?

The one I had problems with was a bit smaller than the Coriolan, 
so you probably have the biggest Lilypond score so far. The good
news is that there's no inherent limit in the program itself, the
bad news is that you need lots of RAM unless you're willing to
wait a night or two for the computer to swap memory back and forth.
I hope you've seen the property Score.skipTypesetting which can be
used to speed up the turn-around time while you correct the errors
in a score. 

      /Mats