Crash on export as .ogg

[Tantacrul]

Describe the bug
Tested in the latest nightly on MacOS. Choosing to export as a .ogg file (4100 Hz or 48000 Hz) causes an immediate crash.

To Reproduce
Steps to reproduce the behavior:

1. Choose any file
2. Export as ogg
3. Crash occurs after you select your location

Happens regardless of whether Muse Sounds or Muse Basic is chosen. Tested on Beta candidate and Nightly.

[Tantacrul]

Note. VST does not seem relevant because if I change everything to MS Basic, the crash still occurs. Even with a new score, it occurs. 100% reproducible on MacOS for me.

04_Export_OGG_2.mov

[cbjeukendrup]

My experience in a nightly build:

• Exporting ogg always causes crash

My experience in a self-built version on macOS 13 beta with Xcode 14.1 beta SDK and whatever:

• Exporting ogg with 44100Hz (which matches my currently selected speakers) works totally fine
• Exporting ogg with other sample rate
  • in a score with Muse Sounds gives a progress bar eternally stuck at 0%, with barely any CPU usage. Maybe a deadlock in MuseSampler?? When I make a snapshot in Activity Monitor, I do see something about a std::mutex::lock(), but of course that doesn't mean a deadlock per se...
  • otherwise also works perfectly fine

[Tantacrul]

OK, so @vpereverzev - perhaps it only happens with nightlies, which might be why you, Roman and Elnur can't reproduce it?

[HemantAntony]

@Tantacrul I can't reproduce this on Linux when you build it. Same with the Nightly. Can't reproduce

[krtschil]

On Linux this happens:

1. Open score
2. Export to .ogg / .mp3 / .flac / .pdf /.png (maybe all formats are affected) and choosing the location
3. .ogg / .mp3 / .flac / .pdf /.png files are created successfully
4. Closing the score resulted in immediate crash
5. Leftover from the opened score: < filename >.autosave
6. When selecting only one part the crash does not happen
7. Same behaviour with other scores: exporting one part seems to be o.k. but selecting all parts results in the crash (tested with a second score: same behaviour as with the score below)

Crash message
Several of these messages:
[16254:16254:20221013,132442.039278:ERROR process_reader_linux.cc:520] no module mappings 0x7f1a24729000
[16254:16254:20221013,132442.039303:ERROR elf_image_reader.cc:116] no preferred header address
[16254:16254:20221013,132442.039308:ERROR process_reader_linux.cc:520] no module mappings 0x7f1a246ff000
[16254:16254:20221013,132442.039503:ERROR elf_dynamic_array_reader.h:61] tag not found

/tmp/.mount_MuseSc6b8Omr/AppRun: Zeile 26: 14678 Speicherzugriffsfehler "${APPDIR}/bin/mscore4portablenightly" "$@"

Conjecture
This type of crash might be related to report #13698 as the offending action is the same (clicking on the X to close the score).

Attachment
Log file
Opened Score

MSD4.zip

Klaus

[cbjeukendrup]

@krtschil I think indeed that that is a different crash than what we experience on macOS. The macOS crash is specifically related to OGG and happens immediately when trying to export to OGG.

[AntonioBL]

Ciao.
I could reproduce the crash in a 64bit Linux Mint 20.3 virtual machine (VirtualBox running inside a Windows 7 pc), with both a nightly build and a local (debug) build.
In my machine, the crash occurs with an Illegal Instruction (SIGILL) here.
I tried to make small changes around that point in the code, but whenever the program was creating or casting a float or a double, it emitted the Illegal Instruction error. I also tried to play with opus options, but I got no positive results.
Then I saw this issue report: xiph/opus#154 and I thought that maybe that could be the culprit; I applied the related patch ( mumble-voip/opus@b7dc80cb4207595 ) and the resulting binaries do not crash anymore for me.
Could it be the same problem also for MacOS? If so, I would expect it to appear only for "old" hardware.

( By the way, among the opus options there is one labelled OPUS_CUSTOM_MODES "Enable non-Opus modes, e.g. 44.1 kHz & 2^n frames"; at the moment it is OFF, but shouldn't we enable it, if we want to export 44.1 kHz output? Or maybe this is not related to output sampling rate...)

[AntonioBL]

@Tantacrul : you can try this build, to check if also under Mac it is the same problem of SSE-optimized instructions:
https://github.com/AntonioBL/MuseScore/suites/8809133343/artifacts/400823174
It is the artifact of this test branch: https://github.com/AntonioBL/MuseScore/tree/oggcrash where I simply introduced the patch already present in upstream opus.
Ciao,
ABL

[cbjeukendrup]

@AntonioBL This seems to work perfectly for me on macOS, huge thanks!

@Tantacrul @vpereverzev check this out :)

[Tantacrul]

Just tested with MS Basic (Reunions) and a String Quartet using VSTi. In both cases, no problems with export. Great stuff!

@vpereverzev - if you are happy with this, can it be merged?

[vpereverzev]

SSE

@AntonioBL great stuff! Open a PR and I'll push dat "merge" button so hard!

[AntonioBL]

The commit is already present in opus master branch, but it is not yet part of a released version.
Can we simply copy it into MuseScore? Or does the existence of MuseScore CLA create problem in merging that commit?

[vpereverzev]

The commit is already present in opus master branch, but it is not yet part of a released version. Can we simply copy it into MuseScore? Or does the existence of MuseScore CLA create problem in merging that commit?

Shouldn't be a problem, just make sure to keep their copyrights in the header of the file

[AntonioBL]

Ok, I will do.
Thank you.