"Phil Holmes" <[email protected]> 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 <[email protected]> > 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
