On 12/7/11 1:48 PM, "Craig" <craigbakal...@verizon.net> wrote:
>Hi Mike, > >I have found out what it is. It has to do with the midi output. If I >remove the \midi {} from my project there are not segmentation faults. >So this has to be a memory allocation issue inside the lily machine. So now how could anybody at lilypond troubleshoot this? There is no way for us to reproduce it, so we can't investigate it. If we solved the problem, how would we know? Will my system behave the same as your system? If not, is it because of a different operating system, a different memory size, or some other reason? In order for us to even begin to look at the problem you're having, we need access to a copy of the problematic file. Even if the file is *huge*, at least we can see if the problem occurs on our machines as well as on yours. If it works on mine, and fails on yours, then we'll need to compare software and OS versions. You haven't given that information, so we can't do that. Is this segmentation fault due to the number of staves, or the number of notes, or something else? Can you eliminate some of the non-tuba staves, and see if you still get the problem? Can you eliminate some of the previous measures in all of the voices/staves and still get the problem? Can you do something like myMusic = \repeat unfold 100 {a4 a a a} \score { \new StaffGroup << \new Staff { \myMusic } \new Staff { \myMusic } \new Staff { \myMusic } >> \layout {} \midi {} } and change the number of staves and the number of measures (via \repeat unfold) and see if you get the error when the number of staves or the number of measures gets too big? Since including the \midi {} block causes the problem, can you explore whether the problem is too many midi voices? Can you create two separate \score blocks in your file, one with a \layout {} and the other with a \midi {}, to see if you still get the segfault? If we donĀ¹t have access to your code, it's like my telling you "My car won't start. Any idea what's wrong?" If we *do* have access to your code, and it's very complicated, we are not very likely to do lots of detailed troubleshooting, but at least we can test whether the problem is reproducible. And we *might* be willing to try one or two things to see if we can make it work. If you come to the list with very little information and no code available, and ask us what's wrong, we can't possibly tell you. We don't have any idea. If you come to the list with that same little bit of information, and ask us for ideas about how you can troubleshoot it, we might have some suggestions. If by following those suggestions, you are able to come up with a simple (but not necessarily *short*) lilypond file that shows the behavior, then we have a great chance to troubleshoot it. For an example of how this worked on another bug that showed up only in a complex score (Valentin's opera), see Issue 1475 <http://code.google.com/p/lilypond/issues/detail?id=1475&can=1&q=unfold&col spec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary> This started out as a crash only on valentin's opera. Pal then found a way to use \repeat unfold to make a simple (but long) score that got the same error. Then we could start experimenting simply with the code to find when the bug was introduced. And it was a straightforward fix for the person who knew the right code. So we can't work miracles to fix your problem. But we can work with you to help you get to a state where there's a good enough bug report to fix the problem. I hope this helps, Carl _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user