Re: Lilypond 2.23.0 crashes on layout
W dniu 16.02.2021 o 18:33, Jonas Hahnfeld pisze: Usual disclaimer that LilyPond doesn't fully support Guile 2.2 (yet), so you'll definitely see worse performance (mostly slower startup) and might run into occasional issues, like this one. Guile 1.8 should be the safer choice for now (if you still have it in Gentoo). I tried to track back the moment the issue was introduced, but then found out that guile 2.x has been supported for two versions only, so I stopped digging. Good to know. That said, I've seen this issue before during my tests with Guile 2.2 (Translators being collected while still referenced somewhere), but never had a stack trace to investigate. So it's already great to have that, but do I read this correctly that you can reliably reproduce the issue on your system? I'm asking because I can't on mine (Arch Linux) and in fact, your file works just fine for me. So finding out how to trigger this kind of bugs more reliably would be a huge step. On my box lilypond crashes every single time I command it to produce PDFs (never does if not told to lay out), so I think I can provide much help, maybe core files, or recorded execution from GDB (never tried to do it before, though). Regarding AddressSanitizer, did you just compile LilyPond with it or all dependencies? I didn't attempt so far because I thought it wouldn't work, but maybe I should try? I just set CFLAGS='-fsanitize=address -g' and LDFLAGS='-fsanitize=address' before configuring lilypond, and installed the debug symbols for guile, so that AddressSanitizer could resolve function names from it. ASAN wiki suggests to mainly compile executables with it, because it does not support sanitized libraries used with not sanitized executables (or it does, but requires preloading it manually). But maybe sanitizing some library too would help additionally? I could try it if you want, but sanitizing guile might break[1] (I have not tried). Gentoo gives extreme flexibility as to managing compile-time options, while handling the burden of building everything one thing at a time, so this does not pose any problem for me (I don't recommend setting up a Gentoo VM just for tests, unless you are patient, since building lilypond and deps from a base system takes at least an hour). (It could of course be an issue in one of the libraries, especially the stack trace in Pango looks odd, but it's equally possible that it's a heap corruption bug that may show in the least expected places...) (These heap bugs are the worst...) -- Arusekk [1]: https://github.com/hannob/asantoo/blob/add80838689755e74a6c1ca793c49b9dd9c50fcb/sys-devel/asantoo-base/files/package.env-asantoo#L12 ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lilypond 2.23.0 crashes on layout
Am Dienstag, dem 16.02.2021 um 15:44 +0100 schrieb Arusekk:
> Hello lilypond crew!
>
> Reporting the bug here, since I saw on the bug link that you prefer mail
> over GitLab issues.
>
> When trying to process any file with \layout{} directive, lilypond
> crashes (Segmentation fault / address not mapped).
>
> I was able to reproduce it on current git master
> (2c9361d3d2d9e9bdfca626d01076c94fb81e2e88) as well.
>
> My distro: Gentoo Linux
>
> Installed (possibly relevant) library versions:
>
> [IP-] [ ] dev-scheme/guile-2.2.7:12/2.2-1
>
> [IP-] [ ] x11-libs/pango-1.42.4-r2:0
>
> [IP-] [ ] dev-libs/boehm-gc-8.0.4:0
Usual disclaimer that LilyPond doesn't fully support Guile 2.2 (yet),
so you'll definitely see worse performance (mostly slower startup) and
might run into occasional issues, like this one. Guile 1.8 should be
the safer choice for now (if you still have it in Gentoo).
> typescript.txt contains colored output (made with `script` utility,
> contains ANSI escapes, view best with cat or less -R) from lilypond
> being run under AddressSanitizer, which suggests that there is a
> use-after-free bug, while processing the example from snk6.ly; it also
> fails to process files as simple as `\score{c \layout{}}`, though
> providing arguably less helpful, but distinctly different output
> (attached as basic.txt).
That said, I've seen this issue before during my tests with Guile 2.2
(Translators being collected while still referenced somewhere), but
never had a stack trace to investigate. So it's already great to have
that, but do I read this correctly that you can reliably reproduce the
issue on your system? I'm asking because I can't on mine (Arch Linux)
and in fact, your file works just fine for me. So finding out how to
trigger this kind of bugs more reliably would be a huge step.
Regarding AddressSanitizer, did you just compile LilyPond with it or
all dependencies? I didn't attempt so far because I thought it wouldn't
work, but maybe I should try?
Jonas
>
> I was not able to create such a minimal input file that would trigger
> the helpful trace.
>
> Off-topic, I believe I transcribed the piece to sound pretty accurately,
>
> but I have not seen the layout yet (because of the bug), so please don't
> tell me that it renders ugly.
>
> Million thanks for such an awesome piece of software anyway :)
>
> Please let me know if you need more info, or if the bug should be
> reported to one of the libraries instead.
(It could of course be an issue in one of the libraries, especially the
stack trace in Pango looks odd, but it's equally possible that it's a
heap corruption bug that may show in the least expected places...)
signature.asc
Description: This is a digitally signed message part
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Lilypond 2.23.0 crashes on layout
Hello lilypond crew!
Reporting the bug here, since I saw on the bug link that you prefer mail
over GitLab issues.
When trying to process any file with \layout{} directive, lilypond
crashes (Segmentation fault / address not mapped).
I was able to reproduce it on current git master
(2c9361d3d2d9e9bdfca626d01076c94fb81e2e88) as well.
My distro: Gentoo Linux
Installed (possibly relevant) library versions:
[IP-] [ ] dev-scheme/guile-2.2.7:12/2.2-1
[IP-] [ ] x11-libs/pango-1.42.4-r2:0
[IP-] [ ] dev-libs/boehm-gc-8.0.4:0
typescript.txt contains colored output (made with `script` utility,
contains ANSI escapes, view best with cat or less -R) from lilypond
being run under AddressSanitizer, which suggests that there is a
use-after-free bug, while processing the example from snk6.ly; it also
fails to process files as simple as `\score{c \layout{}}`, though
providing arguably less helpful, but distinctly different output
(attached as basic.txt).
I was not able to create such a minimal input file that would trigger
the helpful trace.
Off-topic, I believe I transcribed the piece to sound pretty accurately,
but I have not seen the layout yet (because of the bug), so please don't
tell me that it renders ugly.
Million thanks for such an awesome piece of software anyway :)
Please let me know if you need more info, or if the bug should be
reported to one of the libraries instead.
--
Arusekk
\version "2.14.0"
signa = {
\time 4/4
\tempo 4 = 144
\key cis \minor
}
ini = \relative c'' {
<< {
cis2\fff bis |
cis
} \\ {
dis,2\fff e |
dis
} >>
}
inii = \relative c'' {
e,4\ gis
}
dro = \relative c'' {
cis'8\f b a gis |
}
drond = \relative c'' {
cis8 b a gis |
}
ref = \relative c'' {
cis2 e8 cis\staccato cis\staccato cis\staccato |
cis gis'\staccato gis\staccato gis\staccato gis4
}
refr = \relative c'' {
e8 dis |
}
reff = \relative c'' {
cis4\staccato cis'\staccato cis,\staccato cis'\staccato |
}
refe = \relative c'' {
\reff |
cis8 cis'\staccato cis\staccato cis\staccato
}
refcd = \relative c'' {
cis'2 |
}
refbg = \relative c'' {
f'4.\mf e16 d e4 c |
d4. c16 bes c4 a |
bes4. a16 g a4 f |
e a g8 f e f |
d2 e4 c |
r4 f'4 e8 d c4 |
d c a c |
d2.. a16 c |
d4 d a8 g f4 |
r e f e8 a16 c |
d4. a16 c d4. a16 c |
d1 |
}
strsolo = \relative c'' {
e8\mf dis fis e gis fis a gis |
fis gis e dis e gis dis gis |
cis, gis cis dis e gis, dis' e |
cis gis cis gis cis gis gis'4 |
}
versea = \relative c' {
e4\mf\> fis8 dis~dis e~e cis |
}
verseb = \relative c' {
r8\mp dis8~dis bis~bis gis~gis gis |
}
versec = \relative c' {
r8\mp b'8~b cis~cis4 r4 |
}
refA = \relative c'' {
r4 a4 r a |
r a r f8 e |
r4 d'4 r d |
a8 a a4 a a8 bes |
r4 a4 r a |
r a r f8 e |
r4 d'4 r d |
a8 a a4 a a8 bes |
}
bri = \relative c'' {
cis8\ff cis bis bis
}
bria = \relative c'' {
cis8 cis cis cis |
}
brib = \relative c'' {
cis8 cis gis gis
}
endung = \relative c'' {
a'8 gis fis gis fis e fis e |
dis e dis cis dis bis cis r |
}
\score {
<<
\new Staff {
\signa
\clef treble
\relative c'' {
\set Staff.midiInstrument = #"acoustic grand"
% gpno
\ini \inii |
\ini \dro |
\ini \inii |
\ini \drond |
\ini \inii |
\ini \drond | % ref end
\ini \inii |
\ini \drond | % violin solo end
\ini \inii |
\ini \drond |
\ini \inii |
\ini
\key d \minor
\transpose cis d {
\dro |
r1 r r r |
r1 r r r |
% refbg enters
r1 r r r |
r1 r r r |
r1 r r r |
}
\key cis \minor
% gpno
\bri \bri |
\bri \bria |
\bri \bri |
\brib \bria |
\bri \bri |
\bri \bria |
}
}
\new Staff {
\signa
\clef treble
<<
\new Voice {
\relative c'' {
\set Staff.midiInstrument = #"choir aahs"
gis4\ a~a fis~ |
fis1 |
gis4 a~a fis |
b2\<
% choir
\dro |
\ref \refr |
\ref r4 |
\ref \refr |
\refe \refcd |
r1 r r r | % violin solo end
\set Staff.midiInstrument = #"synth voice"
% voice
\versea |
\verseb |
\versea |
\versec |
\versea |
\verseb |
cis8\> cis cis cis~cis cis~cis4 |
r2
\set Staff.midiInstrument = #"choir aahs"
\key d \minor
<<
\transpose cis d {
% choir
\dro |
\ref \refr |
\ref r4 |
\ref \refr |
\refe \dro |
\ref \refr |
\ref r4 |
\ref \refr |
\refe \refcd |
r1 r | % there should be a little voice solo here
\refe \refcd |
} \\ {
r2 |
Re: \center-column broken
> Inkscape works very well to convert PDFs to SVG, but if we expect > our users to do that, then it's debatable whether we should have an > SVG backend at all. I agree. However, my SVG knowledge is very small; this means I'm not qualified to make any decisions. > (I mean this seriously: the SVG backend has its own bugs that are > hard to fix; we have no way, currently, to regtest it; and we could > get LilyPond to call inkscape itself where it is available and SVG > is the specified backend; just a thought...) Please raise these topics on the 'lilypond-devel' mailing list! 'bug-lilypond' is probably the wrong one. It probably also makes sense to file issues in the tracker. Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \center-column broken
On Tue, 16 Feb 2021 at 08:44, Werner LEMBERG wrote: > > > > How about hosting the fonts on www.lilypond.org and referencing them > > in the @font-face definition? > > I think this is not a good idea. I agree that hosting fonts would be a headache: everyone's svg documents would suddenly depend on lilypond.org. I am sympathetic to the idea that we should embed the fonts in the SVG, or perhaps provide a command-line option to tell LilyPond to do so. Inkscape works very well to convert PDFs to SVG, but if we expect our users to do that, then it's debatable whether we should have an SVG backend at all. (I mean this seriously: the SVG backend has its own bugs that are hard to fix; we have no way, currently, to regtest it; and we could get LilyPond to call inkscape itself where it is available and SVG is the specified backend; just a thought...) Kevin ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \center-column broken
> How about hosting the fonts on www.lilypond.org and referencing them > in the @font-face definition? I think this is not a good idea. * LilyPond fonts change from version to version, quite often in a backwards-incompatible way. Hosting them for SVG access would enforce us to completely revise how fonts are named and accessed – and versioned. To a certain extent this will become better if the transition to SMuFL is done, but it still complicates things. * It would be necessary to serve subsetted fonts, too; otherwise, the internet bandwidth would be far too large. LilyPond has zero support for that. * Contrary to fonts, hinting does not make sense for most musical glyphs. In other words, the benefit of accessing LilyPond graphical objects (grobs) as real glyphs in fonts is zero. * Serving non-musical fonts would be definitely out of scope for 'lilypond.org'. What exactly do you want to achieve? What kind of SVGs do you need? In previous e-mails I mentioned two solutions how SVGs could be improved: * using inkscape's option `-T` to convert glyphs to outlines * conversion from PDF to SVG with inkscape Doesn't this suffice? Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
