Menu
▾
▴
#3432 skylined text alongside a staff consumes all memory under Windows
Originally created by: *anonymous
Originally created by: k-ohara5...@oco.net
Originally owned by: dak@gnu.org
Many cases are causing LilyPond under MS Windows to fail with an allocation failure, after first consuming all memory.
For example, reduced from "Largo"
{\tempo "rg" s1}
Some things that avoid the problem are shown with %%
Putting the tempo mark in its own context, or avoiding tight-fitting skylines.
%%\new Dynamics \with {\consists Metronome_mark_engraver }
\new Staff { %% \new RhythmicStaff
%%\override Score.MetronomeMark #'vertical-skylines = #'()
\tempo rg s1 }
Originally posted by: dak@gnu.org
(No comment was entered for this change.)
Labels: OpSys-Windows
Originally posted by: PhilEHol...@googlemail.com
Update: I reckon I now know how to get GUB to make only Windows binaries, so I'll get on this after a day working tomorrow. I hope to be able to identify the commit during Thursday.
Originally posted by: k-ohara5...@oco.net
Another example that exhausts memory on Windows
<< \new Dynamics {s1}
\new Lyrics \lyricmode { u } >>
does not use the code for outside-staff placement, so the start of problem can only bet the patch for issue 3383, commit [r04ce84386dc022316c347ee0c5049c852eea3421]
It is feasible to try fixing this while keeping the chain of issues 3383, 3161, etc., fixed, but we should be conservative because running GUB to test every change is not reasonable. We would need to make the code affected by the patch for issue 3383 robust to differences in floating-point implementations.
Originally posted by: dak@gnu.org
As noted in issue3383, there was one iteration of the code that ran into the "eats-all-memory" symptom on GNU/Linux, and the difference between "works" and "explodes" was one condition that was < rather than <= or vice versa. That would indicate one spot that is highly sensitive to numeric fluctuations. It may or may not be the one that fails under Windows, but it would at least be a starting point for investigation.
As I am working on a complete reimplementation (which takes its time) due to the overall quality of the code, I don't really want to invest time here myself, so the fastest measure would likely be a simple revert without further investigation. The problem solved by the patch seems quite less urgent than the problem it likely bought us.
Originally posted by: PhilEHol...@googlemail.com
OK - I can confirm that a revert of Issue 3383 allows me to build a Windows binary that successfully compiles the test in comment #1. Pulling from master and building the binary without the revert displays the prior behaviour of consuming all available memory and crashing. Developers - we have a fix. Who wants to commit the revert?
I would also plan a GUB build this weekend once this is in master.
Originally posted by: dak@gnu.org
Pushed to staging as
commit [r2210b8053b053726ae598f31b62456df1e4db82b]
Author: David Kastrup <dak@gnu.org>
Date: Thu Jul 11 16:49:59 2013 +0200
Revert "Issue3383: old-straight-flag + smaller Stem.thickness gives no output and huge over"
This reverts commit [r04ce84386dc022316c347ee0c5049c852eea3421].
This is a temporary measure for dealing with issue 3432.
Labels: Fixed_2_17_22
Owner: dak@gnu.org
Status: Fixed
Originally posted by: dak@gnu.org
Issue 3434 has been merged into this issue.
Related
Issues:
#3434Originally posted by: Elu...@gmail.com
(No comment was entered for this change.)
Status: Verified