Data entry lag - Memory out of bounds

[karend27]

@lpugin @craigsapp @JRegimbal @martha-thomae @ahankinson

This is an issue I've discussed a bit with Juliette and Laurent and we are unsure if it is a Verovio issue or a Verovio-Humdrum issue.

It's sort of making any kind of data entry on MP Editor impossible.

When I go the music input phase of data entry on MP Editor, there seems to be a lag when you get past a certain number of notes, they don't appear on the staff right away and there is some sort of lag before they appear. I am using Chrome. I haven't noticed that there is a specific number of notes where this happens.

This is an example: on home screen of editor (https://editor.measuringpolyphony.org/#/), entered this URL in the entry box and selected DIAMM as the manuscript repository: https://www.diamm.ac.uk/sources/260/

Then on the music input screen I select the staff and start entering the notes. After 25 notes the notes don't show up on the staff. I just entered notes of all the same rhythm. When I go to the javascript console I get this types of the one error pasted below (I'm also attaching the whole error file as there are a lot of errors):

main.95214dbdc67b9fb6.js:1 ERROR RuntimeError: memory access out of bounds
at 02557a3a:0x649dd
at 02557a3a:0x2b9f4
at 02557a3a:0x21dc37
at 02557a3a:0x3f31b3
at 02557a3a:0x684f2c
at 02557a3a:0x3f5aa1
at 02557a3a:0xa426
at 02557a3a:0xa549
at 02557a3a:0xa549
at 02557a3a:0xa549

Then when I did the second pass and entered the rhythms (9090 etc.), all seemed to work okay, although when I look at Javascript console there are several more memory access errors.

main.95214dbdc67b9fb6.js:1 ERROR RuntimeError: memory access out of bounds
at 02557a3a:0x6ab5
at 02557a3a:0x225bb8
at 02557a3a:0xaf13c
at 02557a3a:0x61437
at 02557a3a:0x408886
at 02557a3a:0x680588
at 02557a3a:0x12414
at 02557a3a:0x3f080f
at 02557a3a:0xa426
at 02557a3a:0xa549
eC @ main.95214dbdc67b9fb6.js:1Understand this error
main.95214dbdc67b9fb6.js:1 ERROR RuntimeError: remainder by zero
at 02557a3a:0x21df39
at 02557a3a:0x3f31b3
at 02557a3a:0x684f2c
at 02557a3a:0x3f5aa1
at 02557a3a:0xa426
at 02557a3a:0xa549
at 02557a3a:0xa549
at 02557a3a:0xa549
at 02557a3a:0x115a40
at 02557a3a:0xe8b01
eC @ main.95214dbdc67b9fb6.js:1Understand this error
main.95214dbdc67b9fb6.js:1 ERROR RuntimeError: null function or function signature mismatch
at 02557a3a:0x21e01c
at 02557a3a:0x3f31b3
at 02557a3a:0x684f2c
at 02557a3a:0x3f5aa1
at 02557a3a:0xa426
at 02557a3a:0xa549
at 02557a3a:0xa549
at 02557a3a:0xa549
at 02557a3a:0x115a40
at 02557a3a:0xe8b01
eC @ main.95214dbdc67b9fb6.js:1Understand this error
2main.95214dbdc67b9fb6.js:1 ERROR RuntimeError: memory access out of bounds
at 02557a3a:0x6ab5
at 02557a3a:0x225bb8
at 02557a3a:0xaf13c
at 02557a3a:0x61437
at 02557a3a:0x408886
at 02557a3a:0x680588
at 02557a3a:0x12414
at 02557a3a:0x3f080f
at 02557a3a:0xa426
at 02557a3a:0xa549

And then when I start adding the text the lagging gets worse, and when I look in the Javascript console there are now 35 memory access errors.

I then entered a second staff - pitches only - and same thing after about 20 notes or so starts lagging. Entering rhythms is mostly ok, text is laggy, and then when I go to console, there are now 62 memory access errors.

I don't know whether this is related, but when I click the button to Continue to score editor, I get this error: Error in scoring up tool! TypeError: Cannot read properties of null (reading 'getElementsByTagName') and nothing shows up in the score editor. There are two new types of errors in the console:

TypeError: Cannot read properties of null (reading 'getElementsByTagName')
at n.runScoringUp (main.95214dbdc67b9fb6.js:1:769878)
at n.ngAfterViewInit (main.95214dbdc67b9fb6.js:1:766231)
at Zm (main.95214dbdc67b9fb6.js:1:26266)
at Do (main.95214dbdc67b9fb6.js:1:26097)
at Rc (main.95214dbdc67b9fb6.js:1:25817)
at qa (main.95214dbdc67b9fb6.js:1:45305)
at LC (main.95214dbdc67b9fb6.js:1:51401)
at vC (main.95214dbdc67b9fb6.js:1:45164)
at qa (main.95214dbdc67b9fb6.js:1:45175)
at Vp (main.95214dbdc67b9fb6.js:1:44729)
runScoringUp @ main.95214dbdc67b9fb6.js:1Understand this error
main.95214dbdc67b9fb6.js:1 ERROR TypeError: Cannot read properties of undefined (reading 'l')
at LA.t (main.95214dbdc67b9fb6.js:1:579642)
at Uq.publish (main.95214dbdc67b9fb6.js:1:520901)
at IZ.publish (main.95214dbdc67b9fb6.js:1:567840)
at IZ.setCurrentPages (main.95214dbdc67b9fb6.js:1:569760)
at Qq.onViewDidUpdate (main.95214dbdc67b9fb6.js:1:527059)
at Object.onViewDidUpdate (main.95214dbdc67b9fb6.js:1:556673)
at JF.goto (main.95214dbdc67b9fb6.js:1:541782)
at IZ.updatePanelSize (main.95214dbdc67b9fb6.js:1:560389)
at IZ.onResize (main.95214dbdc67b9fb6.js:1:560961)
at v.invokeTask (polyfills.7e8b4abbd2c97f33.js:1:7162)
eC @ main.95214dbdc67b9fb6.js:1Understand this error

I've also attached the full copy of the console text, and this is an image of what I was entering.

desmond memory access out of bounds error.log

Thanks for taking a look!

[lpugin]

@craigsapp do you know which version is running at https://verovio-script.humdrum.org/scripts/verovio-toolkit-wasm.js ?

[craigsapp]

It is a fairly new version of verovio (I think I compiled with the latest develop about a week ago). This is the "develop" version of the Humdrum branch of verovio. You could change to one of the verovio github distributions of the similar file to see if it is related to something new (and it is not necessary to use the develop version of the Humdrum branch, and a fixed version from the verovio github website (that processes Humdrum) is probably safer for stability.

[lpugin]

I won't be able to run it locally, but I can debugging if I know what data input is passed to Verovio. Does any body know it?

[lpugin]

Actually it is not clear that the problem is Verovio. It is in fact looking more like an issue in the JS code of the application.

[JRegimbal]

Could you elaborate on what kind of issue you think it is, @lpugin? It looks like the loadData function in the toolkit is where the out of bounds error originates in the stack trace (below), so I'm curious if there's some way we could be calling it "wrong" that leads to this behavior.

$func44 (02557a3a:0x6ab5)
$func2398 (02557a3a:0x225bb8)
$func985 (02557a3a:0xaf13c)
$func716 (02557a3a:0x61437)
$func3652 (02557a3a:0x408886)
$func6393 (02557a3a:0x680588)
$func163 (02557a3a:0x12414)
$func3452 (02557a3a:0x3f080f)
$func83 (02557a3a:0xa426)
$func83 (02557a3a:0xa549)
$func83 (02557a3a:0xa549)
$func83 (02557a3a:0xa549)
$func83 (02557a3a:0xa549)
$func83 (02557a3a:0xa549)
$func1437 (02557a3a:0x115c14)
$func1226 (02557a3a:0xe8b01)
$func1669 (02557a3a:0x148043)
$func1916 (02557a3a:0x16a5f7)
$_ (02557a3a:0x45b8d3)
ccall (verovio-toolkit-wasm.js:14)
(anonymous) (verovio-toolkit-wasm.js:14)
(anonymous) (verovio-toolkit-wasm.js:26)
loadData (verovio-toolkit-wasm.js:275)
humdrumToSVG (main.95214dbdc67b9fb6.js:1)
updateSVG (main.95214dbdc67b9fb6.js:1)
handleKeyPress (main.95214dbdc67b9fb6.js:1)
(anonymous) (main.95214dbdc67b9fb6.js:1)
k1 (main.95214dbdc67b9fb6.js:1)
s (main.95214dbdc67b9fb6.js:1)
(anonymous) (main.95214dbdc67b9fb6.js:1)
invokeTask (polyfills.7e8b4abbd2c97f33.js:1)
onInvokeTask (main.95214dbdc67b9fb6.js:1)
invokeTask (polyfills.7e8b4abbd2c97f33.js:1)
runTask (polyfills.7e8b4abbd2c97f33.js:1)
invokeTask (polyfills.7e8b4abbd2c97f33.js:1)
Z (polyfills.7e8b4abbd2c97f33.js:1)
N (polyfills.7e8b4abbd2c97f33.js:1)
B (polyfills.7e8b4abbd2c97f33.js:1)

[craigsapp]

Can the js toolkit be switched to one that is at least a few months old (one with Humdrum included). If it runs without errors, then the verovio code is the culprit. Maybe trying version 4.5.1:

version-4.5.1

[JRegimbal]

Thanks for the suggestion! I cannot produce the same behavior with v4.5.1 of verovio-toolkit-hum.js.

[lpugin]

Good. Can you narrow it down to the version that introduced the problem?

[craigsapp]

There are 6 releases since 4.5.1:

https://github.com/rism-digital/verovio/releases

(I would start with one in the middle, and if that works go to next recent one, or if it does not work, then go to the next previous one).

[JRegimbal]

From some quick testing, it looks like the change occurred between versions 5.1.0 and 5.2.0.

[lpugin]

Can you give the options set and the input data that crashes it? I'll try to fix it. In the meantime, you can also set the editor to use 5.1.