Re: .ly file partially compiles, then LP crashes

[Thomas Morley]

2017-07-29 9:53 GMT+02:00 Knut Petersen :
> Am 29.07.2017 um 09:01 schrieb David Kastrup:
>>
>>
>> Uh, the proper way to throw in the towel is not a segfault.  If you can
>> find a reproducible manner of segfaulting on a hard page break problem,
>> that warrants fixing.
>
>
> I remember segfaults that looked exactly like Guys, but those scores have
> changed a lot and I don't
> have the old versions. Maybe I find something in old backups.
>
> One score that reliably segfaults with global staff size above a certain
> limit is attached to issue #5169,
> but I think that segfault is caused by a different problem.
>
> Knut

Confirmed segfault for this score on Ubuntu 16.04 64-bit with LilyPond 2.19.65,
Pity I can't test with 2.18.2 and before because you frequently used
new features like
fis8. 16 8

Btw, undertie _is_ implemented in the source.


Cheers,
  Harm

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

Re: .ly file partially compiles, then LP crashes

[David Kastrup]

Knut Petersen  writes:

> Am 29.07.2017 um 09:01 schrieb David Kastrup:
>>
>> Uh, the proper way to throw in the towel is not a segfault.  If you can
>> find a reproducible manner of segfaulting on a hard page break problem,
>> that warrants fixing.
>
> I remember segfaults that looked exactly like Guys, but those scores
> have changed a lot and I don't
> have the old versions. Maybe I find something in old backups.
>
> One score that reliably segfaults with global staff size above a
> certain limit is attached to issue #5169,
> but I think that segfault is caused by a different problem.

No idea.  This occurs for stuff that fails to have a system assigned for
whatever reason while code depends on it.  I am trying to figure out
right now if it should.

-- 
David Kastrup

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

Re: .ly file partially compiles, then LP crashes

[Knut Petersen]

Am 29.07.2017 um 09:01 schrieb David Kastrup:


Uh, the proper way to throw in the towel is not a segfault.  If you can
find a reproducible manner of segfaulting on a hard page break problem,
that warrants fixing.


I remember segfaults that looked exactly like Guys, but those scores have 
changed a lot and I don't
have the old versions. Maybe I find something in old backups.

One score that reliably segfaults with global staff size above a certain limit 
is attached to issue #5169,
but I think that segfault is caused by a different problem.

Knut



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

Re: .ly file partially compiles, then LP crashes

[David Kastrup]

Knut Petersen  writes:

> Hi Guy!
>
>> Starting lilypond-windows.exe 2.19.56
>> [Leloupgarou_transformationscene-pianoReduction.ly]...
>>
>> Processing `[filename].ly'
>>
>> Parsing...
>>
>> Interpreting
>> music...[8][16][24][32][40][48][56][64][72][80][88][96][104][112][120][128][136][144][152][160][168][176][184][192][200][208][216][224][232]
>>
>> Preprocessing graphical objects...
>>
>> Interpreting music...
>>
>> MIDI output to `[filename].mid'...
>>
>> Finding the ideal number of pages...
>>
>> Fitting music on 9 or 10 pages...
>>
>> Drawing systems...
>>
>> warning: compressing over-full page by 7.1 staff-spaces
>>
>> warning: page 3 has been compressed
>>
>> Exited with return code -1073741819.
>
> Try to play with set-global-staff-size.
>
> It's definitely possible to find combinations of global staff size,
> page-count, system-count, etc
> and music that are hard or impossible to solve. I remember more than
> one segfault caused
> by such an exercise. That problem is old, it is also reproducible on
> linux systems and current
> git master.

Uh, the proper way to throw in the towel is not a segfault.  If you can
find a reproducible manner of segfaulting on a hard page break problem,
that warrants fixing.

-- 
David Kastrup

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

Re: .ly file partially compiles, then LP crashes

[Knut Petersen]

Hi Guy!


Starting lilypond-windows.exe 2.19.56 
[Leloupgarou_transformationscene-pianoReduction.ly]...

Processing `[filename].ly'

Parsing...

Interpreting 
music...[8][16][24][32][40][48][56][64][72][80][88][96][104][112][120][128][136][144][152][160][168][176][184][192][200][208][216][224][232]

Preprocessing graphical objects...

Interpreting music...

MIDI output to `[filename].mid'...

Finding the ideal number of pages...

Fitting music on 9 or 10 pages...

Drawing systems...

warning: compressing over-full page by 7.1 staff-spaces

warning: page 3 has been compressed

Exited with return code -1073741819.




Try to play with set-global-staff-size.

It's definitely possible to find combinations of global staff size, page-count, 
system-count, etc
and music that are hard or impossible to solve. I remember more than one 
segfault caused
by such an exercise. That problem is old, it is also reproducible on linux 
systems and current
git master.

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

Re: .ly file partially compiles, then LP crashes

[David Kastrup]

Guy Stalnaker  writes:

> And it happened twice more, too.

Any reason you are using an old development version?

-- 
David Kastrup

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

Re: .ly file partially compiles, then LP crashes

[Guy Stalnaker]

And it happened twice more, too.

Last time I tried to add \clef "treble" and then \clef bass to the score 
and the same seg-fault/error recurred. A quick test showed that just 
adding \clef "treble" was enough to cause the seg-fault (if that's what 
is happening).


Nothing I can do to make that not happen. I admit I am making liberal 
use of << { } \\ { } >>, and even, in some places, creating ossia and, 
in one of the ossia nesting even more of these contexts, so I may indeed 
be taxing the code in unusual ways.


But, for now it's done and I'm getting ready to send it to the composer 
for her review.


Thanks for all the comments, etc.

Guy

On 7/28/2017 1:23 AM, Thomas Morley wrote:

2017-07-28 1:16 GMT+02:00 Guy Stalnaker :

Simon,

That was my tack -- the dirty way was to slowly comment out sections and see
what happened. It's the oddest thing. I'm writing a piano reduction mostly
from string parts, so I'm doing this:


pianoRH = {
<< { ViolinI } \\ { ViolinII } >>
}
pianoLH = {
<< { Violo } \\ { Cello } >>
}


As shown, did not compile. Comment out ViolinI, compiles. Add it back,
compile fails. Comment out ViolinII, compiles, add ViolinII back, compile
fails. WTH? So, I think you're right, it's some sort of memory/resource
something.

But ...

I replaced the ViolinI code with the original code (from the composer) AND
IT NOW COMPILES in its entirety.

That is maddening. But, I've no time to waste on it now, and thankfully I've
little hair to pull out over it.

Thanks for your reply, MUCH appreciated.

Guy

On 7/27/2017 6:06 PM, Simon Albrecht wrote:

On 28.07.2017 00:55, Guy Stalnaker wrote:

I'm not trying to figure out how to do something here. This is a code
file that compiled to midi/pdf output a few hours ago (last successful pdf
output at 4:31p CDT).


Can you restore the file version that compiled successfully? Or is there
any other chance of narrowing down the part of the code that’s problematic?
There have been problems with memory that are triggered by the size of the
score, but IIRC those had three-digit page numbers.

Best, Simon


Occasionally I had smiliar problems, with files I was working on.
Eventually I must have added some whitespace-characters at unfortunate
place without noticing.
Because it worked again after doing "Remove Trailing Whitespace"
(provided by my editor).

Cheers,
   Harm


--
“Happiness is the meaning and the purpose of life, the whole aim and end of 
human existence.”
― Aristotle


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

Re: .ly file partially compiles, then LP crashes

[Bernhard Kleine]

Am 28.07.2017 um 18:56 schrieb David Kastrup:
> David Wright  writes:
>
>> On Fri 28 Jul 2017 at 15:16:03 (+0200), David Kastrup wrote:
>>> Bernhard Kleine  writes:
>>>
 Am 28.07.2017 um 00:55 schrieb Guy Stalnaker:
> Exited with return code -1073741819
 This has come up with the same number IIRC repeatedly.
>>> It's Windows' helpful way to refer to a segfault.  Storing something
>>> more descriptive like "Segmentation violation" for several dozen
>>> signal-based error messages would consume too much memory needed for
>>> spyware. 16kB should be enough for anybody.
>> I don't understand what the OS would do with these error messages.
>> On error, the OS returns a code¹ which is handled by the caller.
>> When I run a program under strace, I can see the OS generating
>> hundreds of errors every second and they all go unreported except
>> as a return code. It's up to the application to decide whether to
>> finally report something, and what that is.
> On Posix systems, applications are usually started by the shell and the
> shell translates return codes corresponding to a process aborted by a
> signal to a suitable message.
>
> Why is Windows incapable of doing the same?
>
It happens obviously not often enougp to cause the giant to react.

-- 
spitzhalde9
D-79853 lenzkirch
bernhard.kle...@gmx.net
www.b-kleine.com, www.urseetal.net
-
thunderbird mit enigmail
GPG schlüssel: D5257409
fingerprint:
08 B7 F8 70 22 7A FC C1 15 49 CA A6 C7 6F A0 2E D5 25 74 09




signature.asc
Description: OpenPGP digital signature
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: .ly file partially compiles, then LP crashes

[David Kastrup]

David Wright  writes:

> On Fri 28 Jul 2017 at 15:16:03 (+0200), David Kastrup wrote:
>> Bernhard Kleine  writes:
>> 
>> > Am 28.07.2017 um 00:55 schrieb Guy Stalnaker:
>> >> Exited with return code -1073741819
>> > This has come up with the same number IIRC repeatedly.
>> 
>> It's Windows' helpful way to refer to a segfault.  Storing something
>> more descriptive like "Segmentation violation" for several dozen
>> signal-based error messages would consume too much memory needed for
>> spyware. 16kB should be enough for anybody.
>
> I don't understand what the OS would do with these error messages.
> On error, the OS returns a code¹ which is handled by the caller.
> When I run a program under strace, I can see the OS generating
> hundreds of errors every second and they all go unreported except
> as a return code. It's up to the application to decide whether to
> finally report something, and what that is.

On Posix systems, applications are usually started by the shell and the
shell translates return codes corresponding to a process aborted by a
signal to a suitable message.

Why is Windows incapable of doing the same?

-- 
David Kastrup

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

Re: .ly file partially compiles, then LP crashes

[David Wright]

On Fri 28 Jul 2017 at 15:16:03 (+0200), David Kastrup wrote:
> Bernhard Kleine  writes:
> 
> > Am 28.07.2017 um 00:55 schrieb Guy Stalnaker:
> >> Exited with return code -1073741819
> > This has come up with the same number IIRC repeatedly.
> 
> It's Windows' helpful way to refer to a segfault.  Storing something
> more descriptive like "Segmentation violation" for several dozen
> signal-based error messages would consume too much memory needed for
> spyware. 16kB should be enough for anybody.

I don't understand what the OS would do with these error messages.
On error, the OS returns a code¹ which is handled by the caller.
When I run a program under strace, I can see the OS generating
hundreds of errors every second and they all go unreported except
as a return code. It's up to the application to decide whether to
finally report something, and what that is.

That said, having spent years tracking down 0Cn errors in IBM Fortran,
errors like Access Violation mean next to nothing on their own because
the cause could be many levels of calls and MB of code away from the
point where the faulty address value actually triggers the error.

> It's the same reason that all of ed's (the inspiration for Edlin) error
> messages are a single question mark.

I like the 16kB. Could I just point out that the code for the very
functional EDIT program (I believe Phil Hazel wrote it—he wrote its
successor Zed) occupied 32kB of memory. This single chunk of 32kB
(reentrant) was used by 70-100 people simultaneously logged on to
Phoenix/MVS running on an IBM 370/165 containing 1MB of ferrite core
memory (later increased to 4MB). Meanwhile the system was running a
heavily used batch job service.

¹ Linux has them in include/uapi/asm-generic/errno{-base,}.h
if I'm up to date; Windows will have some equivalent header
file that google will know about.

Cheers,
David.

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

Re: .ly file partially compiles, then LP crashes

[David Kastrup]

Bernhard Kleine  writes:

> Am 28.07.2017 um 00:55 schrieb Guy Stalnaker:
>> Exited with return code -1073741819
> This has come up with the same number IIRC repeatedly.

It's Windows' helpful way to refer to a segfault.  Storing something
more descriptive like "Segmentation violation" for several dozen
signal-based error messages would consume too much memory needed for
spyware. 16kB should be enough for anybody.

It's the same reason that all of ed's (the inspiration for Edlin) error
messages are a single question mark.

-- 
David Kastrup

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

Re: .ly file partially compiles, then LP crashes

[Phil Holmes]

It's Hex C005.  Probably an access violation.

--
Phil Holmes


  - Original Message - 
  From: Bernhard Kleine 
  To: lilypond-user@gnu.org 
  Sent: Friday, July 28, 2017 1:36 PM
  Subject: Re: .ly file partially compiles, then LP crashes


  Am 28.07.2017 um 00:55 schrieb Guy Stalnaker:

Exited with return code -1073741819
  This has come up with the same number IIRC repeatedly. I wonder where the 
return code comes from. 
  If there is such a message there is a reason for it that someone programmed. 
(given that such a message is totally frustrating for the enduser since it does 
not give the reason for the cause. Bad programming style. I know it is not 
lilypond.)

  Bernhard who experienced the same error some time ago,

-- 
spitzhalde9
D-79853 lenzkirch
bernhard.kle...@gmx.net
www.b-kleine.com, www.urseetal.net
-
thunderbird mit enigmail
GPG schlüssel: D5257409
fingerprint:
08 B7 F8 70 22 7A FC C1 15 49 CA A6 C7 6F A0 2E D5 25 74 09

--


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

Re: .ly file partially compiles, then LP crashes

[Bernhard Kleine]

Am 28.07.2017 um 00:55 schrieb Guy Stalnaker:
> Exited with return code -1073741819
This has come up with the same number IIRC repeatedly. I wonder where
the return code comes from.
If there is such a message there is a reason for it that someone
programmed. (given that such a message is totally frustrating for the
enduser since it does not give the reason for the cause. Bad programming
style. I know it is not lilypond.)

Bernhard who experienced the same error some time ago,

-- 
spitzhalde9
D-79853 lenzkirch
bernhard.kle...@gmx.net
www.b-kleine.com, www.urseetal.net
-
thunderbird mit enigmail
GPG schlüssel: D5257409
fingerprint:
08 B7 F8 70 22 7A FC C1 15 49 CA A6 C7 6F A0 2E D5 25 74 09



signature.asc
Description: OpenPGP digital signature
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: .ly file partially compiles, then LP crashes

[David Kastrup]

Thomas Morley  writes:

> Occasionally I had smiliar problems, with files I was working on.
> Eventually I must have added some whitespace-characters at unfortunate
> place without noticing.
> Because it worked again after doing "Remove Trailing Whitespace"
> (provided by my editor).

That would seem to point to problems when some stuff is parsed at a
buffer boundary.  It would be good to track this down but obviously a
"mininmal (non-)working example" is hard to produce when any attempt at
minimalization changes the symptoms.

-- 
David Kastrup

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

Re: .ly file partially compiles, then LP crashes

[Thomas Morley]

2017-07-28 1:16 GMT+02:00 Guy Stalnaker :
> Simon,
>
> That was my tack -- the dirty way was to slowly comment out sections and see
> what happened. It's the oddest thing. I'm writing a piano reduction mostly
> from string parts, so I'm doing this:
>
> 
> pianoRH = {
> << { ViolinI } \\ { ViolinII } >>
> }
> pianoLH = {
> << { Violo } \\ { Cello } >>
> }
> 
>
> As shown, did not compile. Comment out ViolinI, compiles. Add it back,
> compile fails. Comment out ViolinII, compiles, add ViolinII back, compile
> fails. WTH? So, I think you're right, it's some sort of memory/resource
> something.
>
> But ...
>
> I replaced the ViolinI code with the original code (from the composer) AND
> IT NOW COMPILES in its entirety.
>
> That is maddening. But, I've no time to waste on it now, and thankfully I've
> little hair to pull out over it.
>
> Thanks for your reply, MUCH appreciated.
>
> Guy
>
> On 7/27/2017 6:06 PM, Simon Albrecht wrote:
>>
>> On 28.07.2017 00:55, Guy Stalnaker wrote:
>>>
>>> I'm not trying to figure out how to do something here. This is a code
>>> file that compiled to midi/pdf output a few hours ago (last successful pdf
>>> output at 4:31p CDT).
>>
>>
>> Can you restore the file version that compiled successfully? Or is there
>> any other chance of narrowing down the part of the code that’s problematic?
>> There have been problems with memory that are triggered by the size of the
>> score, but IIRC those had three-digit page numbers.
>>
>> Best, Simon


Occasionally I had smiliar problems, with files I was working on.
Eventually I must have added some whitespace-characters at unfortunate
place without noticing.
Because it worked again after doing "Remove Trailing Whitespace"
(provided by my editor).

Cheers,
  Harm

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

Re: .ly file partially compiles, then LP crashes

[Kieren MacMillan]

Hi Guy,

> I'm writing a piano reduction mostly from string parts, so I'm doing this:
> 
> 
> pianoRH = {
> << { ViolinI } \\ { ViolinII } >>
> }
> pianoLH = {
> << { Violo } \\ { Cello } >>
> }
> 
> 
> As shown, did not compile.

Have you thought about trying the partcombiner? Or at least explicitly 
controlling the voices? I would expect the above code (even if de-pseudo-fied) 
to be a good candidate for not working as expected/hoped…

Cheers,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


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

Re: .ly file partially compiles, then LP crashes

[Guy Stalnaker]

Simon,

That was my tack -- the dirty way was to slowly comment out sections and 
see what happened. It's the oddest thing. I'm writing a piano reduction 
mostly from string parts, so I'm doing this:



pianoRH = {
<< { ViolinI } \\ { ViolinII } >>
}
pianoLH = {
<< { Violo } \\ { Cello } >>
}


As shown, did not compile. Comment out ViolinI, compiles. Add it back, 
compile fails. Comment out ViolinII, compiles, add ViolinII back, 
compile fails. WTH? So, I think you're right, it's some sort of 
memory/resource something.


But ...

I replaced the ViolinI code with the original code (from the composer) 
AND IT NOW COMPILES in its entirety.


That is maddening. But, I've no time to waste on it now, and thankfully 
I've little hair to pull out over it.


Thanks for your reply, MUCH appreciated.

Guy

On 7/27/2017 6:06 PM, Simon Albrecht wrote:

On 28.07.2017 00:55, Guy Stalnaker wrote:
I'm not trying to figure out how to do something here. This is a code 
file that compiled to midi/pdf output a few hours ago (last 
successful pdf output at 4:31p CDT).


Can you restore the file version that compiled successfully? Or is 
there any other chance of narrowing down the part of the code that’s 
problematic? There have been problems with memory that are triggered 
by the size of the score, but IIRC those had three-digit page numbers.


Best, Simon


--
“Happiness is the meaning and the purpose of life, the whole aim and end of 
human existence.”
― Aristotle


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

Re: .ly file partially compiles, then LP crashes

[Simon Albrecht]

On 28.07.2017 00:55, Guy Stalnaker wrote:
I'm not trying to figure out how to do something here. This is a code 
file that compiled to midi/pdf output a few hours ago (last successful 
pdf output at 4:31p CDT).


Can you restore the file version that compiled successfully? Or is there 
any other chance of narrowing down the part of the code that’s 
problematic? There have been problems with memory that are triggered by 
the size of the score, but IIRC those had three-digit page numbers.


Best, Simon

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