Re: segfault in grob.cc

[John Galbraith]

   John Galbraith <address@hidden> writes:

   > This is weird: I only get the crash when lilypond is called from ly2dvi.
   > If I call lilypond directly (even if I cut and paste the lilypond command 
   > and arguments from a ly2dvi --verbose run) I don't see the crash.  This 
would
   > seem to violate some physical law, unless it was an environmental
   > issue.

   Hmm.  I've notice something similarly weird before, using python.  I
   wrote a proc-time utility in python, and it ran ok, but would make big
   commands (typically lilypond on the coriolan) segfault:

   > I am suspicious that a recursion this deep is not normal...

   No, it isn't.  So running from python makes LilyPond behave
   differently.  What happens if you change ly2dvi so that instead of
   LilyPond, it invokes bash:

       os.system ('bash')

   At that prompt, you run lilypond, or even gdb lilypond.  Hmm, maybe
   python invokes /bin/sh, which might be another shell?

After digging around, it seems that os.system in the python library calls
system(3) (no big surprise there) which in turns calls /bin/sh to execute
the command.  On linux, /bin/sh is actually bash. 

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.  If I also append  'ulimit -s unlimited', then ly2dvi
*works* all the way through.   It also seems to work with 8192 instead
of unlimited.  

These experiments have been done with about half my score commented
out.  On the full score, with an unlimited stack, lilypond does not
technically crash, but does descend into swapping hell after it says
"paper output to ...".  Would there be something that causes
exponential growth in memory size (stack or otherwise) as a function
of input complexity?

Is it possible that lilypond actually requires a massive stack for
large scores, and that incredibly deep recursion in
Grob::handle_broken_smobs is actually normal behavior?

   So, you probably hit the ulimit of your stack; which causes the
   segfault.  Is it the same under python as directly under bash?

So no, it is not.  Why is this?  I guess I don't understand the
mechanics of the system() calls well enough.  At the moment, I get
it to work by brute forcing the limit along with the call to lilypond.

What is a broken smob, anyway?  Is it possible that my score has some
diabolical feature that makes a bunch of those?

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.  My score also has a lot more meter
changes, tuplets, ties, and articulations than something like the
Coriolan that result in a higher density of graphic objects.  Am I on
the cutting edge of lilypond complexity, or are other users out there
who *are* actually typesetting Mahler or something like that?

Thanks,
        John