Re: Make doc crashing on my PC

[David Kastrup]

"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?

> 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.

-- 
David Kastrup