Crashes on Linux / Assertion '!this->empty()' failed

AndiTheHacker commented 2 months ago

Issue type

Crash or freeze

Description with steps to reproduce

Sadly, reproducing this bug is kinda hard. Im using the flatpak stable version on Linux Mint and had this issue twice now: At some point, certain edits to the score will just make the app crash. If it happens, you can throw the file into garbage, because this specific edit will always make musescore crash. Example: I tried to do some text, and at some point, it crashed. Whenever I tried to edit that text again, to be more specific every time I tried to remove the text or make a change to it that would shorten its overall length, the crash would happen. Second time was a certain note that I wanted to get two semitone steps higher - changing the first step was no problem, but the second step always made it crash. The error from the console is below.

Supporting files, videos and screenshots

/usr/include/c++/13.2.0/bits/stl_vector.h:1232: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::back() [with _Tp = mu::engraving::MeasureBase*; _Alloc = std::allocator<mu::engraving::MeasureBase*>; reference = mu::engraving::MeasureBase*&]: Assertion '!this->empty()' failed.

What is the latest version of MuseScore Studio where this issue is present?

4.4.1 flatpak stable

Regression

I was unable to check

Operating system

Linux Mint

Additional context

No response

Checklist

[X] This report follows the guidelines for reporting bugs and issues
[X] I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
[X] I have attached all requested files and information to this report
[X] I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible

Jojo-Schmitz commented 2 months ago

Flatpak versions are not supported here

cbjeukendrup commented 2 months ago

While what Jojo says is true, it might still be interesting to investigate what's happening here. It reminds me strongly of https://github.com/musescore/MuseScore/issues/20878, which is at least as mysterious and annoying.

If it happens, you can throw the file into garbage, because this specific edit will always make musescore crash.

You might as well consider throwing it at us (packed in a ZIP file), so that we can try investigate the crash 😉 (well, that is, if we can reproduce it. But you're saying that once you've found a specific action in a specific file where the crash reproduces, then it can reproduced reliably by doing that action, right?)

AndiTheHacker commented 2 months ago

Hello, sorry to have you wait. I attached the zip file. Try to delete bar 7, it crashes. My guess is that the problem has to do with how the columns are aligned. When I had problems with the text, it always occured when the text was too long for the column and it would need to go into the next column. And if i removed text, the bars in the latter column would need to go back to the first. But thats just a random guess, I'm really clueless. Especially because every random thing can be the problem. As i already described, i too had problems with changing a note (not even length, just the tone itself)... test.zip

cbjeukendrup commented 2 months ago

Thanks! I can reproduce it, and the crash occurs at the same place as https://github.com/musescore/MuseScore/issues/24705. Curious though that this one doesn't involve systems that become empty. Adding a simple emptiness check is easy enough, but it would be better to investigate what causes this emptiness and whether it is valid at all.

AndiTheHacker commented 2 months ago

Is there a fix that I can do? I need to have done a small project due to Thursday... Maybe a different version you can recommend?

cbjeukendrup commented 2 months ago

You can of course use the official AppImage from MuseScore.org. To use it, you only need to make it executable and then run it, but if you want you can also "install" it by running MuseScore*.AppImage install.

If you need/want to stick to the FlatPak, you can experiment with temporarily adding/inserting measures somewhere, since the crash seems to have something to do with how measures are distributed over systems/pages.

AndiTheHacker commented 2 months ago

Thanks, the AppImage worked! I even got the project ready in time :) As the issue persists with the flatpak version, am I correct not to close this issue?

cbjeukendrup commented 2 months ago

Yes, we'll have to solve it anyway; while the AppImage does not crash, the fact that this FlatPak build with those asserts enabled does crash means that undefined behaviour is being invoked in the AppImage, so there is a chance that this will cause crashes or other problems later on.

musescore / MuseScore