-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory leak upon opening MusicXML file exported from Sibelius #23276
Comments
I should mention that I asked the collaborator to send me the individual parts that he'd tweaked instead of the whole score, and those opened fine. I noticed they'd been exported as .musicxml rather than .mxl files, which I guess might contribute. They're inside the ZIP attached below :) |
The score from musescore#23276 contains a weird situation: notes in voice 2, while there is a measure repeat sign in voice 1. And that repeated for the entire score. The playback model would render a measure repeat in two situations: 1) when finding one 2) when a segment's measure turns out to be a measure repeat measure. "Rendering" means here that it looks back at the previous measure and renders that to the location of the measure repeat. So, for measure 2 of that score from that issue, it would first encounter the measure repeat element and render playback for it, and thus for the voice 2 notes, it would notice that their measure is a measure repeat measure and thus render the measure repeat _again_. So, we re-look at measure 1 twice. For measure 2, that was just a bit wasteful, but on the other hand not catastrophic. Where it gets exciting is _beyond_ measure 2. Measure 3 contains the same situation as measure 2. So, for measure 3, we look back at measure 2 twice. But for each time that we look at measure 2, we look twice at measure 1. So, now we look 4 times at measure 1! And it only gets worse from here; _exponentially_ worse, to be precise. We solve this by only checking whether the current measure is a measure repeat once per staff, i.e. at the first voice. This way, we're back in the linear world. (Well, rendering the n-th measure now takes linear time, so rendering n measures takes quadratic time.)
It turned out that this was not a memory leak, and not even a real infinite loop, but a very bad case of exponential recursion. Fortunately, the solution was not too complicated. |
Issue type
Import/export issue
Bug description
I'm currently collaborating on a score with a Sibelius user. He has sent me a MusicXML file with some changes, and when I open it MuseScore hangs and starts eating memory. The file is only 44KB, and it opens correctly in Soundslice, so I don't think it's corrupted.
I haven't had to import a MusicXML file since I switched to MS4, so I don't know if this is a new problem or if it's been present since the update. I also don't have MS3 installed on my current computer, so I'd rather not check if it opens in that. I do know that it happened both on the previous version I had installed (4.3.1, I believe) and the latest version (4.3.2), as I tried upgrading to see if it would resolve the problem. I definitely have opened MusicXML files from the same collaborator on MuseScore 3 without trouble, but as mentioned I haven't tested this specific file in MS3.
My system is running Windows 11 23H2, a Ryzen 7 7840HS, 32GB DDR5-5600 and a 500GB WD SN740. Let me know if you need anything more from me.
Thanks in advance for your help, and even bigger thanks for the awesome software! :)
Steps to reproduce
*compressed to ZIP as GitHub won't allow me to upload .mxl files
Screenshots/Screen recordings
In the below screenshot:
MuseScore Version
4.3.1, 4.3.2
Regression
I don't know
Operating system
Windows 11 23H2 (build 22631.3737)
Additional context
No response
The text was updated successfully, but these errors were encountered: