Re: Make doc crashing on my PC

[Phil Holmes]

----- Original Message ----- 
From: "David Kastrup" <address@hidden>
To: <address@hidden>
Sent: Saturday, June 22, 2013 5:28 PM
Subject: Re: Make doc crashing on my PC


> "Phil Holmes" <address@hidden> writes:
>
> > For a while, I've been struggling to get make doc working consistently
> > on my build PC.  This has been seen with my patchy failing, as well.
> > I consistently get this in the error log:
> >
> > Changing working directory to: `./out-www'
> > Processing 
> > `/home/phil/lilypond-git/Documentation/ly-examples/orchestra.ly'
> > Parsing...
> > Interpreting music...
> > Preprocessing graphical objects...Segmentation fault
> >
> > Because it only happens on make doc (I can't reproduce it directly)
> > until today I'd not spent the time trying to work out what causes it.
> > I've just spent most of the afternoon on a bisect (once I sorted out
> > my LSR updates...) and have found that the guilty party appears to be
> >
> > 35d5f2e2ff40e0bd35cf00f22c2428eac354e566 is the first bad commit
> > commit 35d5f2e2ff40e0bd35cf00f22c2428eac354e566
> > Author: David Kastrup <address@hidden>
> > Date:   Sat Apr 27 18:31:01 2013 +0200
> >
> >    Let stack-lines deal properly with vertical spacing (X-empty stencils)
> >
> > I have no idea what that commit does, or why it would give my build
> > machine problems, but I'd say I'm about 80% confident that's the
> > offender.
>
> If you can't reproduce it "directly", does that mean that you can
> reproduce it _reliably_?  Meaning that it always or never fails when
> doing the same commit?

Directly = simply compiling the offending code from the command line.  I've 
not had the time to ensure it's reliable - that'll be a job for another day, 
but I will get on to it.

> > FWIW, the build machine is 64 bit, which may be why I see it and
> > others don't.  I guess it's also possible that it's the same thing
> > that is intermittently causing James' patchy problems.
>
> The problem is that this particular commit does nothing in C++.  It
> does, however, employ a new function ly:stencil-stack which has been
> created for that purpose.
>
> Without further information, it will be close to impossible to figure
> out what to do.  How about creating a backtrace?
>
> The way you do that is by setting
> ulimit -c 1000000
> (you can write "unlimited" if you are very sure that your disk space is
> sufficient to contain a complete memory dump) in the shell from which
> you call
> make doc
>
> After the crash, there should now be a file core or lilypond.core or
> similar in the working directory where the crash occured.  You can then
> call
>
> gdb out/bin/lilypond core
>
> and say
>
> bt
>
> in order to get a backtrace.  That would definitely help.  It's either
> the new function, or the page breaker or something else is not happy
> about the new semantics.


I'll have a crack at that as well, thanks.

--
Phil Holmes