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

• Sep 19, 2018 - 16:26
Reported version
P2 - Medium
S2 - Critical

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


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

In reply to by Jojo-Schmitz

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.

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)

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

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.

Regression No
Reproducibility Always
Workaround No

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

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 ) 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
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.

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.