bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Markup in \tempo Is Broken with Lilypond 2.17.21


From: Phil Holmes
Subject: Re: Markup in \tempo Is Broken with Lilypond 2.17.21
Date: Mon, 1 Jul 2013 20:59:07 +0100

"Thomas Morley" <address@hidden> wrote in message news:address@hidden
2013/7/1 David Kastrup <address@hidden>:
David Kastrup <address@hidden> writes:

Russell Cook <address@hidden> writes:

\version "2.17.21"

\score {
<< \new Voice { \time 4/4 \tempo \markup { "Rubato " \concat { \smaller \general-align #Y #DOWN \note #"4" #1 \medium " = ca. 76" } } s1 * 4 } >>
}

Prior to version 2.17.21, the above code compiled without issues. As of
2.17.21, it only compiles if the string between the \markup opener and the \concat block is removed. It does not matter if the string is moved into the \concat block; Lilypond will consume as much memory as possible until it
reaches the 2 GB process cap and crashes.

Please note, this is Lilypond on Windows. I have not yet tested this
code on Mac OS X or Linux.

Don't see this on a 32bit Linux version compiled with
disable-optimising, am now going for the "stock" variant.

And can't see that normally compiled.  So it might be that just the
Windows version, or just the GUB-compiled binaries are affected.

Can you check with some other of the precompiled versions?  Without an
idea how to reproduce, it is hard pinpointing the problem.

--
David Kastrup

I tested

{
\tempo \markup { "123" }
s1
}

with the following OS, LilyPond-version

 On Linux 64-bit Ubuntu 10.04
 with
   2.16.2 (via installer)
   2.17.20 (via installer)
   2.17.21 (via installer)

 On Linux 32-bit Ubuntu 10.04 (LilyDevel)
 with
   2.17.21 (an older selfcompiled version from master)
   2.17.22 (a selfcompiled version from latest master)

No problems at all.

-Harm

As a reference point, the problem on Windows is that it allocates memory like it's going out of fashion - about 2 Gigs in around 10 seconds on my machine, pauses a while with that amount of memory allocated, then crashes with "Drawing systems...terminate called after throwing an instance of 'std::bad_alloc'
 what():  St9bad_alloc"

--
Phil Holmes
Bug Squad




reply via email to

[Prev in Thread] Current Thread [Next in Thread]