Crash on drag'n'droping bracket from palette to a score.
Scenario.
I'm trying to add bracket to my score.
1. Open palette with Brackets
2. Left mouse button down and move mouse to the score to drag'n'drop bracket there
Result: crash when mouse start hovering score rectangle.
Expected: no crashes :)
Info
Crash is because of Q_ASSERT at the scoreElement.cpp: 267.
Call stack:
5 Ms::ScoreElement::writeProperty
scoreElement.cpp 267
6 Ms::Element::writeProperties
element.cpp 499
7 Ms::Bracket::write
bracket.cpp 456
8 Ms::Element::mimeData
element.cpp 770
9 Ms::Palette::mouseMoveEvent
palette.cpp 364
The reason is that 'BracketItem::getProperty' returns 'QVariant()' in case of 'default' value in 'switch' which is not valid.
I've looked at all similar places and found that 'return Element::getProperty(propertyId)' is usually used in 'Element' childs.
There are 3 places where direct 'QVariant()' is returned without calling super getProperty() method:
* BracketItem::getProperty
* Part::getProperty
* Staff::getProperty
I cannot reproduce crash for Part and Staff class 'cause I don't know use cases.
Attachment | Size |
---|---|
Peek 2018-02-09 13-52.gif | 2.62 MB |
Comments
I'm going to add special processing in Bracket::getProperty() method to call 'Element::getProperty()' if 'BracketItem' returned 'QVariant()'. It is seemed to be a correct solution. But I'm not sure about the Part and Staff ones.
Could you assist with the use cases?
I cannot reproduce here with 470095f
Which version of 3.0 dev., and which specific score are you using exactly?
In reply to I cannot reproduce here… by cadiz1
Hi. Thank you for the response!
This is the master revision 2e112abcff53d72ac4c4a3823afcef77b5e20403 which I used to branch PR (not pushed, yet)
System: Ubuntu 17.10
Score is in the attachment.
So, with 2e112ab and 470095f I can't reproduce with the attached score, if I do simply drag and drop brackets on the score.
And I can edit them as expected
However, I can get a crash with these steps (ditto from scratch with eg the SATB template, after deleting the default bracket, then add a new one, edit/extend, and double undo/redo)
1) Drag and drop a bracket
2) Edit it to extend along the system (as the image above)
3) Undo twice
4) Redo twice
At the second redo, I get constantly a crash.
EDIT: and so, here the status of this issue would be active, but by mentioning the double UNDO/REDO
What OS are you using? Could you check the call stack, please? It is indeed very strange, because crash in my case happens exactly because it has to happen. I mean, in terms of code calls and call stack, there couldn't be no crash :)
"What OS are you using? "
Windows 7 and 10
"Could you check the call stack, please?"
Sorry, I can't, I don't know how to get this. I am tester, not developper :)
By experience, sometimes there is some difference in the behaviour with nightlies (downloaded on the site) and builded nightlies. I don't know if it's the case here.
In reply to "What OS are you using? "… by cadiz1
Ok, thank you. I'll check my case using nightly build on Ubuntu. Also, I'll check the case on my Win 10 machine with both nightly and built application.
This always crashes for me, too. I am not sure about your solution, though. What about removing
Q_ASSERT(getProperty(id).isValid());
fromScoreElement::writeProperty(XmlWriter, P_ID)
and addingQ_ASSERT(data.isValid());
toXmlWriter::tag(P_ID, QVariant, QVariant)
after the first two returns and before the switch? It won't matter thatdata
doesn't contain anything, because it won't be trying to write anything anyway, sincedata == defaultData
.In reply to This always crashes for me,… by mattmcclinch
Thank you for your comment! PR is https://github.com/musescore/MuseScore/pull/3458.
Your idea is good and can be done.
BTW, I've fixed the obvious mistake: element property as a COLOR exists for bracket, but incorrectly processed in getProperty(). Am I missing something important?
Now that I've seen what you've done, your solution makes sense to me. After all, there was probably a reason for the Q_ASSERT being where it was in the first place.
Fixed in https://github.com/musescore/MuseScore/commit/5783276f51f24b187c9bf3fba…
Automatically closed -- issue fixed for 2 weeks with no activity.