Memory leak and crash after multiple audio exports (MP3, WAV, OGG, FLAC)

• Sep 19, 2018 - 16:26
Reported version
2.3
Priority
P2 - Medium
Type
Functional
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
MuseScore

After a certain number of file exports (usually over 10) the program crashes. I am using OS: Windows , Arch.: x86_64, MuseScore version (32-bit): 2.3.2, revision: 4592407

Comments

• Sep 19, 2018 - 16:39
Severity ⇒ S2 - Critical
Status (old) patch (code needs review) ⇒ active
Status ⇒ active

There's no patch, so nothing to review.
It is a crash, so critical

Is this related to point 2 of #276352: Fingerings can overlap staccato and tenuto? Is it exporting to any format to just to specific ones, like the audio formats?

I can for example reproduce a crash after up to 15 WAV, MP3, FLAC or OGG exports, but not after more PDF (19, didn't test with more) or MIDI (51, didn't test with more) exports

Reply

• Sep 20, 2018 - 10:05

1) Other report was exporting WAV files.

2) In my case it is exporting to mp3 files and program crashes. On restarting program the exported file had been created but there was nothing in it. Repeating the export is always successful.

Reply

• Sep 20, 2018 - 10:09
Title Crash after multiple exports ⇒ Crash after multiple audio exports (MP3, WAV, OGG, FLAC)

Yes, that other was about WAV, but I can reproduce it with all audio formats (but not with any non-audio formats)

Reply

• Sep 20, 2018 - 14:02

Tempo changes via the play panel are never saved along with the score (and this is by design), just tempo texts and changes to those are being saved.
But this would be an entirely different and unrelated issue altogether anyhow

Reply

• Oct 17, 2018 - 17:55
Title Crash after multiple audio exports (MP3, WAV, OGG, FLAC) ⇒ Memory leak and crash after multiple audio exports (MP3, WAV, OGG, FLAC)

Need to check whether master is affected too
#277225: Memory leak when exporting in MP3 format claims to see a 200k memory leak for each export, for master I can't confirm that, there is a memory increase of 200k during the export, but most of that seems to get released again, leaving some 2-10k per export.
This is with a self built most recent commit, using Qt 5.12 beta1.

Reply

• Oct 30, 2018 - 12:55
Regression ⇒ No
Reproducibility ⇒ Always
Workaround ⇒ No

at least always reproducible in 2.x, and also in master, but there to a much lesser extent

Reply

• Oct 31, 2018 - 12:13

Actually, I see a lot of memory leaks, but none related to the audio export functions.
Attached you can find the report from leaksanitizer, in which I kept only the direct leak items. None of them is related to or called by the savemp3 function.
As a side note, I started dealing with the memory leaks found in the tests, but the work is big, and there are memory access errors which I had to patch (see https://github.com/musescore/MuseScore/pull/4001 ) before even being able to see the leak sanitizer report for some of the tests. See attached diff for an attempt to fix some of the leaks.
I think separate bug reports should be needed for the memory leaks, but they are so many that writing a separate bug report for each of them would probably clog the issue report.

Attachment Size
leaksanitizer_onlydirect.txt 76.25 KB
memory_leak_diff.txt 14.27 KB

Reply

• Oct 31, 2018 - 12:57
Status active ⇒ fixed

If there is none in the audio export of 3.0, we better close this issue

Probably you're right that there isn't a need for every single memory leaks, but one new issue for general memory leaks won't harm.

Reply

• Oct 31, 2018 - 14:32

If you're wondering about how to PR the leaks; either have a single issue for AddressSanitizer leaks and keep pushing to the same PR as long as it's not merged. Once it is, then reopen the issue with a new PR for remaining warnings.

Or group them by module: one for the preferences, one for mixer/playback, one for… In an attempt to find a middle ground between massive work and massive issue tracker overhead.

Reply