Ok. False alarm but hopefully useful info: The error was triggered by two instances of \times which should have been \time . Now my code compiles with either 2.17.13 or 2.17.14.
If it helps I am using lilypond-2.17.14-1.linux-64 Maybe this difference between 2.17.14 and 2.17.13 could be related to work on \tuplet . Thanks, Paul On Wed, Mar 20, 2013 at 10:03:23AM +0100, David Kastrup wrote: > Paul Scott <[email protected]> writes: > > > I get segmentation faults with 2.17.14 on a medium to large set of files > > which compile fine with 2.17.13. I have gotten these errors with some > > other > > recent 2.17.xx versions. I don't believe I will get errors with a > > minimal example. > > > > What evidence can I provide that might help find the problem? > > I tend to do something like > > git log release/2.17.13-1..release/2.17.14-1 > > for "problem occured between x and y" to look for a likely candidate > based on the commit message, and I just did that. Tell you what: easily > a third or more of all commits could be responsible. > > There are two things for circling the problem: one is "git bisect" to > figure out the commit introducing the segfault. If nothing else, we can > then revert the commit until figuring out the problem. The other is > post-mortem-debugging the segfault to figure out the code where things > go wrong. > > Either will require a developer being able to reproduce the problem. > Try reducing a file of yours to a point where the segfault still occurs > but most of the content could get thrown out. > > -- > David Kastrup > > > _______________________________________________ > lilypond-user mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/lilypond-user > _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
