Memory leak when adding lyric text
Reported version
3.0
Type
Functional
Frequency
Once
Severity
S1 - Blocker
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
When entering lyrics, the memory used by the second alpha increased from 199.9 MB to 201 then to 202.2 to 202.8 to 203.6. The number changes are based upon when the cursor is at the start of each syllable. Data came from the windows 10 task manager. After only 32 measures of music, response is so slow that it is now unusable. I'll have to restart MuseScore to enter 10 or 15 more measures before it slows down too much again.
Comments
@ABL is working on memory leaks, see https://musescore.org/en/node/276356#comment-859719, I guess this one here is on his list too
In reply to @ABL is working on memory… by Jojo-Schmitz
This memory leak was not mentioned specifically, so I created this issue.
I just restarted MuseScore in hopes of resetting the memory usage, but it seems version 3 still uses far more memory than needed.
The other two MuseScore instances are version 2.3.2 and 2.2.1 which both have several complete movements from symphonic music open. These score one instanc has over 2 gigs of data and one much less, but the windows memory usage is a fraction of version 3, which has a 78kb score open. MuseScore 3 is unusable, even after restart, due to its slow speed after such a short score is entered.
I am of course sharing all of this info in hopes it will help track down the memory bugs. I didn't see ABL's post from yesterday. He did say individual issue reports might be necessary so this one won't hurt anything. It seems, however, that the that there are probably multiple issues leading to the program slowing down.
From what I can see with LeakSanitizer, the main problem seems to be that, during layout, the list of systems is cleared without them being deleted. See attached log in which I kept only the leaks related to lyric editing.
If I uncomment this line: https://github.com/musescore/MuseScore/blob/4a97692174fc114911fa3a00a7c… then the memory leak in this case disappears (and in other related cases).
However, Werner himself commented this line with commit c333db279
I tried opening the gp3 file in mtest with this line uncommented, and I had no crash (even with AddressSanitizer on and therefore strict checking of memory accesses), but only if also the spanner segments are removed from the system during their deletion (I think this is a different bug), see https://github.com/musescore/MuseScore/pull/4001/files#diff-df29bc1a8e8…
I uncommented the delete again. If one of the deleted systems is still referenced later we will get a crash and can fix the real bug :-)
55db679
Automatically closed -- issue fixed for 2 weeks with no activity.