Wikimedia Bugzilla is closed!

Possibly should be reassigned to wikimedia admins... your reassign skills are appreciated. ;)

Is the "c,4" a typo?

== Example ==
<score>
\header {
  title =       "Something"
  enteredby =   "grin"
}
\version "2.14.2"
\relative c' { 
c e c e g2 g2  
c,4 e c e g2 g2   
c4 b a g f2 a2 
g4 f e d c2 c2
}
</score>

Not that I know (which doesn't tell really much :-)). I am 5 minutes deep in Lilypond's manual and it seems like a valid "octave down" order.

Actually the error is the same for <score>{ c }</score>.

The latter errors are somewhat usless as the earlier step hasn't finished.

(In reply to comment #3)
> Actually the error is the same for <score>{ c }</score>.

This minimal test case works for me: https://en.wikipedia.org/w/index.php?title=User:Reedy/score&oldid=551798236


Using your full version I get "No MIDI file generated despite being requested. If you are working in raw LilyPond mode, make sure to provide a proper \midi block."


Andre: I notice this component doesn't have an assignee or even a CC. Think we might want to try poking people outside the "WMF group" (ie not Tim/Jan) and get some CC's added. Have CC' Beau as he has done some work to the extension

https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/Score.git;a=search;s=grafzahl;st=author doesn't have a useable email address

Holy cow. Yeah, { c } works, { d } doesn't, and neither does { c c }. Beats me.

Oh. I guess I figured it out.

{ c } works. 
{ c  } doesn't work.

{ c d } works, while { c  d } doesn't.

Seems somehow it's extremely sensitive to punctuation and whitespaces. Lilypond itself doesn't seem to care, the extension somehow does.

If I try something on huwp it usually fails. If I copy it verbatim to enwp it works. When I try again preview on huwp it works there too.

Created attachment 12162 [details]
https://hu.wikipedia.org/w/index.php?title=Szerkeszt%C5%91:Grin/lilypond&oldid=13505682

Testing all the simple examples (ie the extra spaces) work fine locally on my dev wiki. Likely slightly newer lilypond related dependencies

So does https://hu.wikipedia.org/w/index.php?title=Szerkeszt%C5%91:Grin/lilypond&oldid=13505682

See attached PNG. There's a lot of whitespace for some reason, but that's a different issue

@reedy: I have created a large one on huwp failing, copied to your page, working, copied back to huwp, working (probably came from the cache, it was immediate), I have made a trivial change, failing, copied to enwp, working.

Try change my page on huwp.

All wikis run from the same set of apaches, so it's weird it apparently works on enwiki but not huwiki

REEDY ARE THE BUGFIXERER!

<Reedy> enwiki IS running different code to huwiki
<Reedy> as enwiki is on 1.22wmf2 (note, I changed it yesterday)
<Reedy> try it on huwiki *now*
<grin> works

This is happening again: https://zh.wikipedia.org/w/index.php?title=User:Shizhao/score&oldid=26336897&uselang=en

this code works

<score>
\new PianoStaff <<
   % RH Staff
   \new Staff {
      \clef treble
      \key g \major
      \time 3/4
      \relative c'''{
         g4 g( a8.\mordent) b16 |
         a8 \appoggiatura g fis \appoggiatura e d2 |
         g,4\mordent g4.\downprall fis16 g|
      }
   }
   \new Staff {
     \clef bass
     \key g \major
      \time 3/4
        g4 g g
        g g g
        e e e 
}
>>
</score>

but it's impossible to go on coding without getting a GS error.
just add one note 

<score>
\new PianoStaff <<
   % RH Staff
   \new Staff {
      \clef treble
      \key g \major
      \time 3/4
      \relative c'''{
         g4 g( a8.\mordent) b16 |
         a8 \appoggiatura g fis \appoggiatura e d2 |
         g,4\mordent g4.\downprall fis16 g| a
      }
   }
   \new Staff {
     \clef bass
     \key g \major
      \time 3/4
        g4 g g
        g g g
        e e e 
}
>>
</score>

As an aside, this error (comment 14) is not reproducible for me locally using the score extension. It is producible on enwiki. I also had some weird stuff happening where some things seemed to not render on ukwiki, and then I tried it on enwiki, and then it worked everywhere (presumably due to being a cache hit). But that only happened with some examples I tried, not all, so maybe coincidence
----

btw, I believe ghostscript error code 9 is for invalid file access.

*** Bug 47826 has been marked as a duplicate of this bug. ***

As a note, when I hit memory limits on my local install, the error message looks quite different. I also had to significantly decrease the memory limit before the example file hit it. OTOH my local install isn't using cgroups...

*** Bug 47589 has been marked as a duplicate of this bug. ***

>btw, I believe ghostscript error code 9 is for invalid file access.

Actually nevermind, in guile, if you kill a subprocess executed with the (system) command, the return status is the signal that killed it, so in this case SIGKILL (signal 9), which is what would happen if ghostscript exceeded resource limits when using cgroups. (Internally ghostscript also uses 9 to mean invalid file access I believe, but I don't think it actually uses that as a return code)

Which brings up the question of why is it only gs that is exceeding resource limits. I would expect it to be other parts of the rendering process as well. And specifically which limit is being exceeded. Is ghostscript really that expensive? [I don't have cgroups set up locally, but using ulimits, the process completes with much less memory then the limit is set to on wmf wikis]

To further add mystery, on test.wikipedia.org, this issue does not happen. I occasionally got a return status from lilypond of 137 (128 + signal number 9 for bash signalling that it was killed, again presumably due to cgroups). In general though rendering succeeds. Which is odd, since even though test.wikipedia.org is not the same as a normal cluster wiki, afaik it has resource limits configured in the same way [Unless it is perhaps configured as an image scalar?]

[As an aside this provides a very poor workaround, since once you get something rendered on test, it gets cached, and can be used on the other wikis]


-----
In case its later useful, it can be determined what the precise gs command being executed by lilypond by addding -dverbose to the lilypond command line.

*** Bug 48465 has been marked as a duplicate of this bug. ***

*** Bug 48779 has been marked as a duplicate of this bug. ***

For those following along here:

Could someone provide some examples (more than a couple) of reasonably complex (but not unrealistically so) scores that are causing this out of memory issue? This would be helpful for us (WMF) to determine what kind of limit is reasonable. There will still be technical limits on the server side, so it'll be a balancing act, but for now let's see what kind of things are realistic.

(In reply to comment #22)
> For those following along here:
> 
> Could someone provide some examples (more than a couple) of reasonably
> complex
> (but not unrealistically so) scores that are causing this out of memory
> issue?
> This would be helpful for us (WMF) to determine what kind of limit is
> reasonable. There will still be technical limits on the server side, so it'll
> be a balancing act, but for now let's see what kind of things are realistic.

Two examples from plwikisource:

https://pl.wikisource.org/wiki/Kategoria:Pages_with_score_rendering_errors

(In reply to comment #23)
> Two examples from plwikisource:
> 
> https://pl.wikisource.org/wiki/Kategoria:Pages_with_score_rendering_errors

I rendered this one locally:

<https://pl.wikisource.org/wiki/Dyskusja_strony:PL_Tarnowski-Szkice_helweckie_i_Talia.djvu/099>

The image size is 487 x 1401. Lilypond specifies the "png16m" device to GhostScript, which implies 6 bytes per pixel, which is only 4MB for the whole surface. Perhaps the startup overhead of GhostScript and Lilypond puts it on the edge of an OOM, so that you only need a tiny extra image surface to push it over.

https://gerrit.wikimedia.org/r/#/c/73720/ brings down the memory use enough to render the failing scores here.