Re: Strange LilyPond crash

[Michael Gerdau]

> Here's the file... Edski-2015-11-16_v4_test.ly
>  st.ly>

No problem compiling this file and creating a PDF using the current
LilyPond 2.19.32 running from inside Frescobaldi 2.18.1 on an ArchLinux
x86_64 running a Kernel 4.2.5.

Kind regards,
Michael
-- 
 Michael Gerdau   email: m...@qata.de
 GPG-keys available on request or at public keyserver

signature.asc
Description: This is a digitally signed message part.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange LilyPond crash

[Thomas Morley]

2015-11-25 20:30 GMT+01:00 Edward Ardzinski :
> Here's the file... Edski-2015-11-16_v4_test.ly
> 



lilypond Edski-2015-11-16_v4_test.ly
GNU LilyPond 2.18.2
Processing `Edski-2015-11-16_v4_test.ly'
Parsing...
Interpreting music...[8][16][24][32]
Preprocessing graphical objects...
Interpreting music...
MIDI output to `Edski-2015-11-16_v4_test.midi'...
Finding the ideal number of pages...
Fitting music on 1 or 2 pages...
Drawing systems...
Layout output to `Edski-2015-11-16_v4_test.ps'...
Converting to `./Edski-2015-11-16_v4_test.pdf'...
Success: compilation successfully completed

No problem here. Being on Ubuntu 15.04 64-bit

Please try to compile it directly via command-line, to exclude a
frescobaldi-issue.


Cheers,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange LilyPond crash

[Edward Ardzinski]

Here's the file... Edski-2015-11-16_v4_test.ly

  



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Strange-LilyPond-crash-tp183610p184124.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange LilyPond crash

[David Kastrup]

Edward Ardzinski  writes:

> I don't know if I'm stumbling on something similar, but I can't believe that
> it's a large file issue - the piece is about 50 bars of mostly slow 7 with a
> repeat unfolded, two voices and a 2 part drum staff, no lyrics, and done
> entirely with 2.18.2

Not the same bug, then.

> I got to the final dozen bars, and was compiling a score block for the midi
> with the drums, and a pdf score without.  I added the final variable with
> the coda, and got:
>
> Starting lilypond-windows.exe 2.18.2 [Edski-2015-11-16 v4 test.ly]...
> Processing
> `c:/users/edward/appdata/local/temp/frescobaldi-cyoxhi/tmpcpyl1r/Edski-2015-11-16
> v4 test.ly'
> Parsing...
> Interpreting music...[8][16][24][32]
> Exited with return code -1073741819.
>
> Eventually I added the drums, the pdf works fine.

Could be a gc-related Heisenbug as well, but also could be something
else.  Hard to tell without more information.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange LilyPond crash

[Marc Hohl]

Am 24.11.2015 um 17:11 schrieb David Kastrup:

Marc Hohl  writes:


Am 24.11.2015 um 00:12 schrieb Thomas Morley:
[...]


So,
commit b416f10429d8d3881445d9000ff422dc67176df1
Author: David Kastrup 
Date:   Wed Jul 15 23:30:30 2015 +0200

  Issue 3693: Let Percent_repeat_iterator be unfazed by Timing changes

  There is still one shortcoming: the percent repeats will not contain any
  material apart from the percent itself.  In particular, no Timing
  changes will be repeated.  If there are meter changes or \partial
  commands inside of percent repeats, they need to occur in parallel
  passages outside of any percent repeat, if necessary in a separate
  "timing track".

is indeed the problem.


Thanks for your work on this issue!


And for me in creating it.


Hey, that's no problem at all – your work for LilyPond is just great, 
and the speed in which errors like these are corrected is just awesome!


Marc

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange LilyPond crash

[Edward Ardzinski]

I don't know if I'm stumbling on something similar, but I can't believe that
it's a large file issue - the piece is about 50 bars of mostly slow 7 with a
repeat unfolded, two voices and a 2 part drum staff, no lyrics, and done
entirely with 2.18.2

I got to the final dozen bars, and was compiling a score block for the midi
with the drums, and a pdf score without.  I added the final variable with
the coda, and got:

Starting lilypond-windows.exe 2.18.2 [Edski-2015-11-16 v4 test.ly]...
Processing
`c:/users/edward/appdata/local/temp/frescobaldi-cyoxhi/tmpcpyl1r/Edski-2015-11-16
v4 test.ly'
Parsing...
Interpreting music...[8][16][24][32]
Exited with return code -1073741819.

Eventually I added the drums, the pdf works fine.



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Strange-LilyPond-crash-tp183610p184079.html
Sent from the User mailing list archive at Nabble.com.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange LilyPond crash

[Thomas Morley]

2015-11-24 17:11 GMT+01:00 David Kastrup :
[...]
>
> Ticket created at: https://sourceforge.net/rest/p/testlilyissues/issues/4670/
>
> --
> David Kastrup

You already pushed it, so I tested Marc's files with a build including
your patch.
As far as I can tell, all works fine now.

Many thanks,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange LilyPond crash

[David Kastrup]

Marc Hohl  writes:

> Am 24.11.2015 um 00:12 schrieb Thomas Morley:
> [...]
>>
>> So,
>> commit b416f10429d8d3881445d9000ff422dc67176df1
>> Author: David Kastrup 
>> Date:   Wed Jul 15 23:30:30 2015 +0200
>>
>>  Issue 3693: Let Percent_repeat_iterator be unfazed by Timing changes
>>
>>  There is still one shortcoming: the percent repeats will not contain any
>>  material apart from the percent itself.  In particular, no Timing
>>  changes will be repeated.  If there are meter changes or \partial
>>  commands inside of percent repeats, they need to occur in parallel
>>  passages outside of any percent repeat, if necessary in a separate
>>  "timing track".
>>
>> is indeed the problem.
>
> Thanks for your work on this issue!

And for me in creating it.

>> Now it would be nice I'd could come up with a tiny example...
>>
>> Though, very strange things happen, like:
>>
>> assume file-1.ly with
>>
>> foo = { some-music }
>> buzz = { some-other-music }
>>
>> and
>>
>> file-2.ly with
>>
>> \include "file-1.ly"
>> \score {
>><<
>>\new Staff \foo
>>\new Staff \buzz
>>>>
>>
>> compiling file-2.ly causes a segfault.
>> commenting \new Staff \buzz still causes a segfault
>> additional commenting(!) buzz = { some-other-music } in file-1.ly,
>> and the segfault disappears!!!
>> But it's not consistent! It depends what else is defined in those files.
>
> Yep. Moreover, if I removed some notes from buzz, the segfault
> disappeared, but adding one single note causes Lilypond to crash,
> and we talk about scores with 3-5 pages or even less.

Garbage collection errors tend to behave somewhat erratically.

Ticket created at: https://sourceforge.net/rest/p/testlilyissues/issues/4670/

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange LilyPond crash

[Marc Hohl]

Am 24.11.2015 um 00:12 schrieb Thomas Morley:
[...]


So,
commit b416f10429d8d3881445d9000ff422dc67176df1
Author: David Kastrup 
Date:   Wed Jul 15 23:30:30 2015 +0200

 Issue 3693: Let Percent_repeat_iterator be unfazed by Timing changes

 There is still one shortcoming: the percent repeats will not contain any
 material apart from the percent itself.  In particular, no Timing
 changes will be repeated.  If there are meter changes or \partial
 commands inside of percent repeats, they need to occur in parallel
 passages outside of any percent repeat, if necessary in a separate
 "timing track".

is indeed the problem.


Thanks for your work on this issue!



Now it would be nice I'd could come up with a tiny example...

Though, very strange things happen, like:

assume file-1.ly with

foo = { some-music }
buzz = { some-other-music }

and

file-2.ly with

\include "file-1.ly"
\score {
   <<
   \new Staff \foo
   \new Staff \buzz
   >>

compiling file-2.ly causes a segfault.
commenting \new Staff \buzz still causes a segfault
additional commenting(!) buzz = { some-other-music } in file-1.ly,
and the segfault disappears!!!
But it's not consistent! It depends what else is defined in those files.


Yep. Moreover, if I removed some notes from buzz, the segfault 
disappeared, but adding one single note causes Lilypond to crash,

and we talk about scores with 3-5 pages or even less.


No idea how to boil it down to a small example.


Sorry for the initial wrong info,


No problem at all – thanks for your time and work!

Marc


   Harm




___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange LilyPond crash

[Thomas Morley]

2015-11-22 1:59 GMT+01:00 Thomas Morley :
> 2015-11-21 17:31 GMT+01:00 Thomas Morley :
>> 2015-11-21 16:42 GMT+01:00 David Kastrup :
>>> Marc Hohl  writes:
>>>
 As soon as I remove an instrumental part at random (or even some
 notes), the crash may or may not disappear. I am not sure but IIRC a
 file that compiled fine during one run crashed without having done any
 changes to that specific file (nor its includes).  Is it possible that
 the self-compiled version I am using has some internal errors that may
 cause the crash? I update the git repository regularly and re-compile
 lilypond after applying the latest patches.
>>>
>>> Both 2.19.29 and 2.19.30 had really bad problems that could be
>>> exacerbated by "large files".  Your segfault does not look related to
>>> that as far as I can tell.
>>>
>>> --
>>> David Kastrup
>>
>>
>>
>> Hi Marc,
>>
>> I'd like to offer you send me the zipped files offlist.
>> Maybe a second pair of eyes watching the real code may help.
>>
>> Cheers,
>>   Harm
>
> Hi Marc,
>
> thanks for your files.
> Up to know I can't come up with a tiny example.
>
> Though, some observations:
> (1)
> All works with 2.18.2 (after downgrading the syntax)
> (2)
> Replacing all occurances of
> \repeat percent ...
> with
> \repeat unfold ...
> make it work with a build from latest master
>
> Thus I suspected
>
> commit [rb416f10429d8d3881445d9000ff422dc67176df1]
> Author: David Kastrup 
> Date:   Wed Jul 15 23:30:30 2015 +0200
>
> Issue 3693: Let Percent_repeat_iterator be unfazed by Timing changes
>
> There is still one shortcoming: the percent repeats will not contain any
> material apart from the percent itself.  In particular, no Timing
> changes will be repeated.  If there are meter changes or \partial
> commands inside of percent repeats, they need to occur in parallel
> passages outside of any percent repeat, if necessary in a separate
> "timing track".
>
> Which was the last commit I found for this area of code.
>
> Though a build from one commit before:
> cd3c64ba5131d64d7f0b76487054f8fac1364e61
> returned the same segfaults.
>
> Will continue testings tomorrow.
>
> Cheers,
>   Harm

Ok, made a mistake.

One commit before is:
11a9e5701316d46d34993fadb85482282c9753cc

A build from this one works!

So,
commit b416f10429d8d3881445d9000ff422dc67176df1
Author: David Kastrup 
Date:   Wed Jul 15 23:30:30 2015 +0200

Issue 3693: Let Percent_repeat_iterator be unfazed by Timing changes

There is still one shortcoming: the percent repeats will not contain any
material apart from the percent itself.  In particular, no Timing
changes will be repeated.  If there are meter changes or \partial
commands inside of percent repeats, they need to occur in parallel
passages outside of any percent repeat, if necessary in a separate
"timing track".

is indeed the problem.


Now it would be nice I'd could come up with a tiny example...

Though, very strange things happen, like:

assume file-1.ly with

foo = { some-music }
buzz = { some-other-music }

and

file-2.ly with

\include "file-1.ly"
\score {
  <<
  \new Staff \foo
  \new Staff \buzz
  >>

compiling file-2.ly causes a segfault.
commenting \new Staff \buzz still causes a segfault
additional commenting(!) buzz = { some-other-music } in file-1.ly,
and the segfault disappears!!!
But it's not consistent! It depends what else is defined in those files.

No idea how to boil it down to a small example.


Sorry for the initial wrong info,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange LilyPond crash

[David Kastrup]

Marc Hohl  writes:

> Am 21.11.2015 um 16:54 schrieb David Kastrup:
>> Marc Hohl  writes:
>>
>>> Am 21.11.2015 um 10:53 schrieb David Kastrup:
 Marc Hohl  writes:
>>> [...]
 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.
>>>
>>> I am not sure whether I understand this correctly, but I have replaced
>>> every occurence of \addlyrics with its proper counterpart \new Lyrics
>>> \lyricsto "..."
>>
>> Sorry to have caused extra work, but lyricsto and addlyrics are the same
>> with regard to the context hierarchy.  This would not likely have
>> changed anything.
>
> No problem at all – IIRC, \addlyrics seems to be less robust than
> \lyricsto (at least in some cases), isn't it?

No.  \addlyrics is exactly as robust as the corresponding \lyricsto
construct.  It's just that in more complex \addlyrics situations, the
corresponding \lyricsto construct might end up being a bit of a
surprise.

Which reminds me that I still need to fix the latest such discovered
\addlyrics surprise.  Which turned out to be rather tricky.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange LilyPond crash

[Marc Hohl]

Am 21.11.2015 um 16:54 schrieb David Kastrup:

Marc Hohl  writes:


Am 21.11.2015 um 10:53 schrieb David Kastrup:

Marc Hohl  writes:

[...]

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.


I am not sure whether I understand this correctly, but I have replaced
every occurence of \addlyrics with its proper counterpart \new Lyrics
\lyricsto "..."


Sorry to have caused extra work, but lyricsto and addlyrics are the same
with regard to the context hierarchy.  This would not likely have
changed anything.


No problem at all – IIRC, \addlyrics seems to be less robust than 
\lyricsto (at least in some cases), isn't it?


Marc



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange LilyPond crash

[David Kastrup]

Marc Hohl  writes:

> Am 21.11.2015 um 10:53 schrieb David Kastrup:
>> Marc Hohl  writes:
> [...]
>> 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.
>
> I am not sure whether I understand this correctly, but I have replaced
> every occurence of \addlyrics with its proper counterpart \new Lyrics
> \lyricsto "..."

Sorry to have caused extra work, but lyricsto and addlyrics are the same
with regard to the context hierarchy.  This would not likely have
changed anything.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange LilyPond crash

[Thomas Morley]

2015-11-21 17:31 GMT+01:00 Thomas Morley :
> 2015-11-21 16:42 GMT+01:00 David Kastrup :
>> Marc Hohl  writes:
>>
>>> As soon as I remove an instrumental part at random (or even some
>>> notes), the crash may or may not disappear. I am not sure but IIRC a
>>> file that compiled fine during one run crashed without having done any
>>> changes to that specific file (nor its includes).  Is it possible that
>>> the self-compiled version I am using has some internal errors that may
>>> cause the crash? I update the git repository regularly and re-compile
>>> lilypond after applying the latest patches.
>>
>> Both 2.19.29 and 2.19.30 had really bad problems that could be
>> exacerbated by "large files".  Your segfault does not look related to
>> that as far as I can tell.
>>
>> --
>> David Kastrup
>
>
>
> Hi Marc,
>
> I'd like to offer you send me the zipped files offlist.
> Maybe a second pair of eyes watching the real code may help.
>
> Cheers,
>   Harm

Hi Marc,

thanks for your files.
Up to know I can't come up with a tiny example.

Though, some observations:
(1)
All works with 2.18.2 (after downgrading the syntax)
(2)
Replacing all occurances of
\repeat percent ...
with
\repeat unfold ...
make it work with a build from latest master

Thus I suspected

commit [rb416f10429d8d3881445d9000ff422dc67176df1]
Author: David Kastrup 
Date:   Wed Jul 15 23:30:30 2015 +0200

Issue 3693: Let Percent_repeat_iterator be unfazed by Timing changes

There is still one shortcoming: the percent repeats will not contain any
material apart from the percent itself.  In particular, no Timing
changes will be repeated.  If there are meter changes or \partial
commands inside of percent repeats, they need to occur in parallel
passages outside of any percent repeat, if necessary in a separate
"timing track".

Which was the last commit I found for this area of code.

Though a build from one commit before:
cd3c64ba5131d64d7f0b76487054f8fac1364e61
returned the same segfaults.

Will continue testings tomorrow.

Cheers,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange LilyPond crash

[Thomas Morley]

2015-11-21 16:42 GMT+01:00 David Kastrup :
> Marc Hohl  writes:
>
>> As soon as I remove an instrumental part at random (or even some
>> notes), the crash may or may not disappear. I am not sure but IIRC a
>> file that compiled fine during one run crashed without having done any
>> changes to that specific file (nor its includes).  Is it possible that
>> the self-compiled version I am using has some internal errors that may
>> cause the crash? I update the git repository regularly and re-compile
>> lilypond after applying the latest patches.
>
> Both 2.19.29 and 2.19.30 had really bad problems that could be
> exacerbated by "large files".  Your segfault does not look related to
> that as far as I can tell.
>
> --
> David Kastrup



Hi Marc,

I'd like to offer you send me the zipped files offlist.
Maybe a second pair of eyes watching the real code may help.

Cheers,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange LilyPond crash

[David Kastrup]

Marc Hohl  writes:

> As soon as I remove an instrumental part at random (or even some
> notes), the crash may or may not disappear. I am not sure but IIRC a
> file that compiled fine during one run crashed without having done any
> changes to that specific file (nor its includes).  Is it possible that
> the self-compiled version I am using has some internal errors that may
> cause the crash? I update the git repository regularly and re-compile
> lilypond after applying the latest patches.

Both 2.19.29 and 2.19.30 had really bad problems that could be
exacerbated by "large files".  Your segfault does not look related to
that as far as I can tell.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange LilyPond crash

[Marc Hohl]

Am 21.11.2015 um 10:53 schrieb David Kastrup:

Marc Hohl  writes:

[...]

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.


I am not sure whether I understand this correctly, but I have replaced 
every occurence of \addlyrics with its proper counterpart \new Lyrics 
\lyricsto "..."



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


The lilypond files are structured this way:

 - for each song, I have a file -Noten.ily that contains all
   instrumental and choral parts
 - for each instrument, there is a file -.ly that
   includes the -Noten.ily file and picks up the parts associated
   to that instrument
 - for each song, there is a -Partitur.ly file that includes the
   -Noten.ily and displays all the stuff nicely.

If I compile every -.ly file, no errors occur (with 
exeption of the Finale-Drums.ly mentioned earier in this thread), but 
most (but not all) -Partitur.ly files crash. There is no obvious

connection to a specific instrument that may cause the crash, as every
instrumental part occurs at least one in the -.ly file.

All instrumental parts have exactly the same number of measures, so I 
can't see a reason for a context dying when another one depending on it 
is still alive.



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.


As soon as I remove an instrumental part at random (or even some notes), 
the crash may or may not disappear. I am not sure but IIRC a file that 
compiled fine during one run crashed without having done any changes to 
that specific file (nor its includes).
Is it possible that the self-compiled version I am using has some 
internal errors that may cause the crash? I update the git repository 
regularly and re-compile lilypond after applying the latest patches.


Marc


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange LilyPond crash

[David Kastrup]

Marc Hohl  writes:

> Am 17.11.2015 um 00:24 schrieb David Kastrup:
>> Marc Hohl  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 
> 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.
> 0x0001 in ?? ()
> (gdb) backtrace
> #0  0x0001 in ?? ()
> #1  0x00636fa9 in Sequential_iterator::pending_moment
> (this=0x13f7fc0)
> at sequential-iterator.cc:241
> #2  0x00636fa9 in Sequential_iterator::pending_moment
> (this=0x10e0440)
> at sequential-iterator.cc:241
> #3  0x00636fa9 in Sequential_iterator::pending_moment
> (this=0x10d1970)
> at sequential-iterator.cc:241
> #4  0x00585709 in Music_wrapper_iterator::pending_moment
> (this=)
> 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

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange LilyPond crash

[Marc Hohl]

Am 17.11.2015 um 00:24 schrieb David Kastrup:

Marc Hohl  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 

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.
0x0001 in ?? ()
(gdb) backtrace
#0  0x0001 in ?? ()
#1  0x00636fa9 in Sequential_iterator::pending_moment 
(this=0x13f7fc0)

at sequential-iterator.cc:241
#2  0x00636fa9 in Sequential_iterator::pending_moment 
(this=0x10e0440)

at sequential-iterator.cc:241
#3  0x00636fa9 in Sequential_iterator::pending_moment 
(this=0x10d1970)

at sequential-iterator.cc:241
#4  0x00585709 in Music_wrapper_iterator::pending_moment 
(this=)

at music-wrapper-iterator.cc:77
#5  0x006438fb in Simultaneous_music_iterator::pending_moment (
this=) at simultaneous-music-iterator.cc:138
#6  0x00585709 in Music_wrapper_iterator::pending_moment 
(this=)

at music-wrapper-iterator.cc:77
#7  0x006438fb in Simultaneous_music_iterator::pending_moment (
this=) at simultaneous-music-iterator.cc:138
#8  0x006436f5 in Simultaneous_music_iterator::process 
(this=0xc8eef0,

until=...) at simultaneous-music-iterator.cc:94
#9  0x00509491 in Global_context::run_iterator_on_me 
(this=this@entry=0xc8d2c0,

iter=iter@entry=0xc8eef0) at global-context.cc:169
#10 0x0050782b in ly_interpret_music_expression 
(mus=mus@entry=0x7fffef05a9d0,

ctx=ctx@entry=0x7fffee8626a0) at global-context-scheme.cc:118
#11 0x00507c44 in ly_run_translator (mus=0x7fffef05a9d0,
output_def=output_def@entry=0x7fffee899290) at 
global-context-scheme.cc:145
#12 0x00627194 in Score::book_rendering 
(this=this@entry=0x1086df0, layoutbook=

0xc8b7f0, default_def=default_def@entry=0xe76370) at score.cc:141
#13 0x0047fc75 in Book::process_score (this=this@entry=0xc86a00,
s=s@entry=0x7fffee899310, 
output_paper_book=output_paper_book@entry=0xc8b780,

layout=layout@entry=0xe76370) at book.cc:225
#14 0x0047ff31 in Book::process (this=this@entry=0xc86a00,
default_paper=, default_layout=0xe76370,
parent_part=parent_part@entry=0x0) at book.cc:302
#15 0x0047ffe7 in Book::process (this=this@entry=0xc86a00,
default_paper=, default_layout=) at 
book.cc:196

#16 0x0047c29a in ly_book_process (book_smob=,
default_paper=0x7fffeffba660, default_layout=0x7fffefe589c0, 
output=0x7283c9e0)

at book-scheme.cc:75
#17 0x77b26b1f in scm_dapply () from /usr/lib/libguile.so.17
#18 0x77b27a3c in ?? () from /usr/lib/libguile.so.17
#19 0x77b30d33 in scm_c_with_fluid () from /usr/lib/libguile.so.17
#20 0x005e3723 in ly_eval_scm (form=form@entry=0x7fffee8e02f0, 
i=...,
safe=safe@entry=false, parser=parser@entry=0xc4fe70) at 
parse-scm.cc:181

#21 0x00705f6e in Lily_lexer::eval_scm (this=this@entry=0xc4ffc0,
readerdata=readerdata@entry=0x7fffee8e02f0, hi=...,
extra_token=extra_token@entry=35 '#') at lexer.ll:1081
#22 0x00719fc7 in Lily_lexer::eval_scm_token (this=0xc4ffc0,
sval=0x7fffee8e02f0, w=...) at ./include/lily-lexer.hh:61
#23 0x0070f96f in yyparse (parser=,
retval=retval@entry=0x7fffc988) at parser.yy:447
#24 0x00719f77 in Lily_parser::do_yyparse_trampoline 
(parser=)

at parser.yy:3866
#25 0x77b30d33 in scm_c_with_fluid () from /usr/lib/libguile.so.17
#26 0x0054b3f8 in Lily_parser::parse_file 
(this=this@entry=0xc4fe70, init=...,

name=..., out_name=...) at li

Re: Strange LilyPond crash

[David Kastrup]

Marc Hohl  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?

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Strange LilyPond crash

[Simon Albrecht]

On 16.11.2015 11:27, Marc Hohl wrote:

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?


Not off the top of my head. I think there’s nothing for it except 
further testing. Please post the smallest version of the code you could 
find which sports the error. One might check

– with which version the error first occurs
– using the same number of notes, but uniform in pitch and/or rhythm
– using normal Staff and Voices (though this will likely not show the 
problem)

– etc.
in order to find some other way of boiling it down.
And if all of this doesn’t work, then you already have got a minimal 
example to use for a bug report – ‘from which nothing can be removed 
without making the bug disappear’.

That’s all ‘wisdom’ I can contribute…

Yours, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user