Editing slur in a score with parts leads to crash
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4785, revision: c1a5e4c
Steps:
1) Score for two instruments, eg two flutes
2) In second staff, enter four eighth notes
3) Generate parts (New all/Ok)
4) Add slur on first eighth note
5) Edit this slur with Ctrl + Right arrow
Result: crash
Note: sometimes, after some attempts with the same test file (so, after a few Save/Reload), the file seems less "instable". The crash may be less easy to get, but possible by editing in the reverse direction (Ctlr + Right arrow + Left arrow). Something not clear. But from a new file, always crash.
See:
Fix version
3.0.1
Comments
Former issue: June 24, 2017
With this nigthly: d9d738d, and the previous - in the scenario described above -, there was another issue. Ie, by editing the slur with double-click (no default right handle drawn when added), there was a jump to the first staff.
Like this:
With the next one (so, the origin of this current issue) : e21398a, this former specific issue is solved, but you get the current crash when editing.
Confirmed bug, happens with eighth notes and smaller (but not quarter notes). Double click the slur on the attached file and press control right more than 2 times.
The cause of the crash can be traced back to this line of code, where the track2 property of the slur is set to the track of the new anchor. The problem is that the track2 value is not adjusted for the corresponding slurs in linked parts. All linked slurs get the same track2 value, which is a mistake. I actually do not think that this line is necessary, since as I understand it, a slur cannot begin in one track and end in another.
> a slur cannot begin in one track and end in another
Actually you can add a slur between notes in different voices or even different staves. Default layout for cross-staff slurs layout may be not very good (see #279182: Cross-staff slurs/ties trying to avoid note on wrong staff) but such slurs are possible anyway.
I've found changing this line of code to be a reinterpret_cast limits the problem only to when the anchor is changed from an eighth note to a quarter note within the score I posted to (Edit: actually, it's just less likely), this is as far as I got but should give someone more experienced an indication of what's going wrong.
See https://github.com/musescore/MuseScore/pull/4503 for a fix.
Fixed in branch master, commit 88662559ca
fix #280690: Editing slur in a score with parts leads to crash
Fixed in branch master, commit a1152b9e8d
Merge pull request #4503 from mattmcclinch/280690-edit-slur
fix #280690: Editing slur in a score with parts leads to crash
Automatically closed -- issue fixed for 2 weeks with no activity.