hang/crash when saving and reopening attached file

Jojo-Schmitz

• Nov 30, 2015 - 11:30

Priority

P1 - High

Type

Functional

Severity

S1 - Blocker

Reproducibility

Always

Status

closed

Regression

Workaround

Project

MuseScore

Tags

2.0.3

Initially reported in https://musescore.org/en/node/89096

Open attached file (it takes quite long to load)
save (under a different name) and close
open the (new) file

Result: it appears to hang, but after quite a long time it crashes

Note: the file saved at step 2 is more than tripple the size of the attached file, where actually I'd expect it to be smaller, as it contains less instruments.
Insetad is does contain more than 6 Million duplicate and repeated entries like
<linkedTo>3</linkedTo>

Happens with MuseScore 2.0.2 as well as with the latest development build, 7321ba6

Attachment	Size
Bidonville_5.mscz	218.63 KB

Comments

Jojo-Schmitz

• Nov 30, 2015 - 11:59

so far I have been unable to get the crash (and a stack trace) when running in a debugger, it loops there for very Long, then just stops silently (with Exit code 3), no stack trace, but the following 'famous' last words:
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

Jojo-Schmitz

• Nov 30, 2015 - 19:35

Here's a previous version of the file in the hope it may help in fixing the issue

Attachment	Size
Bidonville_4.mscz	128.17 KB

Marc Sabatella

• Nov 30, 2015 - 20:23

Without knowing anything about how this file got into this state, I wonder if perhaps it is related to #70146: Explosive accents on Guitar part with linked tab staff?

mcx

• Dec 21, 2015 - 18:23

I've found a repro of going from the correct number of linkedTo elements to the "way too many" state. See bug https://musescore.org/en/node/91351.

Anatoly-os

• Nov 2, 2018 - 08:35

Severity	S2 - Critical	⇒	S1 - Blocker
Priority		⇒	P1 - High
Regression		⇒	No
Reproducibility		⇒	Always
Reported version		⇒	2.1
Workaround		⇒	No