Invalid duration of notes after a plugin use causes crash

• Sep 7, 2018 - 15:29
Reported version
3.0
Priority
P3 - Low
Type
Functional
Severity
S2 - Critical
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project

I have a couple of score that make V3.0 crash. I assume it is due to extracts in the score.

Attachment Size
Cheek to Cheek.mscz 37.07 KB
Autumn Leaves.mscz 26.51 KB

Comments

Title Program crash when loading a score file with extracts Program crash when loading a score 2(.3.2) score with parts in master
Severity S3 - Major S2 - Critical

Fails in an assert:
Fatal: ASSERT: "!isEmpty()" in file C:/Qt/5.9.6/mingw53_32/include/QtCore/qvector.h, line 237 (C:/Qt/5.9.6/mingw53_32/include/QtCore/qvector.h:237, )
In a 32bitMinGW selfbuit)

Running in MSVC shows this to come from Shape Beam::shape() const

Title Program crash when loading a score 2(.3.2) score with parts in master Invalid duration of notes causes crash

The problem is not in parts. But in second staff.

@Bacchushlg: Could you recall how you manage to obtain stemless notes and with unknown value ("invalid duration) ?
"Invalid duration" appears in the status bar after selecting the first F in second staff, and you observe also the symbols values in the toolbar don't react (image below).

duration.jpg

  • With a minimal selection (measure 2) of the first score "Cheek to cheek" (similar issue with the second score), ie: selection.mscz,
    you get a crash in the 2.3.2 with following steps:

1) Load the "selection" file
2) Cut the first note F in second staff
3) "N" -> enter a note
Result: crash

  • With the current 3.0 dev., the file crashes at the opening.

  • The problem/crash is solved by selecting the first F and by clicking on the quarter note value in the toolbar. The second note (Bb) should be in half note (but the crash is solved without doing this) : selection bis.mscz

This file works.
Always the origin of second staff is weird (no instrument in Staff Properties eg)

@Bacchushlg:
I observe you are accustomed to import files from Capella and PDF/Audiveris (or xml, in other thread) : https://musescore.org/en/node/258306 ("missing rests in one voice after import")
Did you make the same thing here, and by adding a second staff to the first one (something like that?)

Well, the second voice is created using the plugin "chordsToNotes" that I have modfied a little (see appended qml file). I adds a sounding chord from the chord text to a newly added voice.
Unfortunately I did not find a way how to set the note length in the script...

Nevertheless it should be assured that MuseScore does not crash when loading such a score. MuseScore 2 works fine with it ;-)

Attachment Size
chordsToNotes1.qml 12.48 KB

Okay, thanks for the plugin info.

"MuseScore 2 works fine with it ;-) "
Well, not really. It's very easy to get crashes with your two files and 2.3.2 (and previous versions BTW)
As written previously, with following steps:

1) Load one file
2) Cut a note (stemless, in second staff, first measure)
3) Press "N" -> Enter eg a C

Result: crash

I see that the missing duration is a problem. Can anybody tell me, how to correct the plugin in order to define the duration of the chords? I try a couple of things, but nothing allowed me to set the duration...

I don't even see this as an issue, and certainly not a blocker. As far as I know, there has never been a version of MuseScore that caused chords to be written without a duration. The problem was introduced with a modified version of a third-party plugin. There is only one person who has this version of the plugin, and now he knows not to use it. We could check each chord read from a score to see if a duration was supplied, but what would be the point?

In reply to by mattmcclinch

It was also my point of view. I imagine the program can not be held responsible for any unfortunate modification of a plugin, which we know, in addition, that some (I can think of "HalfTime" / "Double Time", for example), even when they are not modified, are unstable.

Priority P1 - High P0 - Critical

Blocker is by the matter of severity levels. Crashes are always S1, but priority is indeed low due to the arguments you guys mentioned.