Re: Strange LilyPond crash

[David Kastrup]

Marc Hohl <address@hidden> writes:

> Am 17.11.2015 um 00:24 schrieb David Kastrup:
>> Marc Hohl <address@hidden> writes:
>>
>>> Hi list,
>>>
>>> I am currently reworking some older stuff that compiled perfectly
>>> under 2.13.x
>>>
>>> Yes, I used convert-ly on all files, but nevertheless, I encountered a
>>> strange problem:
>>>
>>> I have a drum part, consisting of an upper and a lower DrumVoice, and
>>> if I try to compile the full Drum score, I get a segfault.
>>>
>>> I tried to reduce the number of notes and realized that if I include
>>> either drum voice, everything is fine.
>>>
>>> Next, I included the complete upper voice and commented out parts of
>>> the lower drum voice. Now lilypond compiles upto a certain point in
>>> the score, but if I include *one more note*, I get the segfault again.
>>>
>>> Well, we talk about 70 measures with eighths, quarter notes and some
>>> triplets, so I don't believe that LilyPond runs out of memory.
>>>
>>> I am currently using 2.19.32.
>>>
>>> Any ideas of what's going wrong here?
>>
>> Any chance for running inside of gdb and get a backtrace?
>>
>
> Ok, this is what I got:
>
> (gdb) run Finale-Drums.ly
> Starting program: /home/marc/git/lilypond/out/bin/lilypond Finale-Drums.ly
> Traceback (most recent call last):
>   File
> "/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19-gdb.py",
> line 63, in <module>
>     from libstdcxx.v6.printers import register_libstdcxx_printers
> ImportError: No module named 'libstdcxx'
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> GNU LilyPond 2.19.32
> »Finale-Drums.ly« wird verarbeitet
> Analysieren...
> Interpretation der Musik...[8][16][24][32][40][48][56][64]
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000000001 in ?? ()
> (gdb) backtrace
> #0  0x0000000000000001 in ?? ()
> #1  0x0000000000636fa9 in Sequential_iterator::pending_moment
> (this=0x13f7fc0)
>     at sequential-iterator.cc:241
> #2  0x0000000000636fa9 in Sequential_iterator::pending_moment
> (this=0x10e0440)
>     at sequential-iterator.cc:241
> #3  0x0000000000636fa9 in Sequential_iterator::pending_moment
> (this=0x10d1970)
>     at sequential-iterator.cc:241
> #4  0x0000000000585709 in Music_wrapper_iterator::pending_moment
> (this=<optimized out>)
>     at music-wrapper-iterator.cc:77

Looks like there is some sequential iterator consulted for
pending_moment that no longer has an iter_ to refer to.

More likely than not, one of the fixes for addlyrics going off the deep
end when its associated context dies is involved here.

So it's likely that near the time in question, some context or lyrics or
other dies and that this has unforeseen repercussions.

> What does this mean?

Well, I hope you can figure out some more of what is involved here,
hopefully to the degree of creating a crash example that is of
manageable size.

-- 
David Kastrup