Strange, no stack trace, no assertion failure, just aborting or exiting with a return value of 3.
Prior to that the following "amous last words":
Debug: unhandled id mag (...\MuseScore\libmscore\staff.cpp:1206, virtual QVariant Ms::Staff::getProperty(Ms::P_ID) const)
Debug: unhandled id mag (...\MuseScore\libmscore\staff.cpp:1206, virtual QVariant Ms::Staff::getProperty(Ms::P_ID) const)
Debug: unhandled id mag (...\MuseScore\libmscore\staff.cpp:1246, virtual bool Ms::Staff::setProperty(Ms::P_ID, const QVariant&))
Hi Jojo
Hope you don't mind me asking but how do you view the stacktrace? Is it withing the IDE or is it the special degbug version of Musescore? What is all the text you have there i.e. .... "Debug: unhandled id mag (...\MuseScore\libmscore\....etc......"
Yes, this is the same, but it can even be reproduced easier:
1) "My First Score"
2) Right-click -> Stave (or Staff) Properties (which English version should be used?)
3) Ok or Apply
As shown by Jojo-Schmitz's stack trace, the problem is unhandled id mag and the abort instruction at line 1247
of libmscore/staff.cpp
Indeed, handling of the property P_ID::MAG in Staff::setProperty was deleted by commit 337e885896
and it was moved to StaffTypeChange::setProperty
The change of property is called in by line 3313
of libmscore/undo.cpp
However, I don't know what should be done in this case, since I am not familiar with the changes Werner is implementing in the "core" objects.
Outch! I missed that abort() instrunction! No wonder there's no stack trace.
Should have used a QFatal() rather than a QDebug() there?
Just deleting that abort() fixes the crash, I can't see any ill effect, except for the continued debug messages, but currently the code is in a pretty bad state, not much works.
Comments
This nightly works: aa98918
Not this one: 6251397
Strange, no stack trace, no assertion failure, just aborting or exiting with a return value of 3.
Prior to that the following "amous last words":
Debug: unhandled id mag (...\MuseScore\libmscore\staff.cpp:1206, virtual QVariant Ms::Staff::getProperty(Ms::P_ID) const)
Debug: unhandled id mag (...\MuseScore\libmscore\staff.cpp:1206, virtual QVariant Ms::Staff::getProperty(Ms::P_ID) const)
Debug: unhandled id mag (...\MuseScore\libmscore\staff.cpp:1246, virtual bool Ms::Staff::setProperty(Ms::P_ID, const QVariant&))
Hi Jojo
Hope you don't mind me asking but how do you view the stacktrace? Is it withing the IDE or is it the special degbug version of Musescore? What is all the text you have there i.e. .... "Debug: unhandled id mag (...\MuseScore\libmscore\....etc......"
I'm using QtCreator and it's debugger
And "all that text" is what I get with the DEBUG Version.
Came up again in #153846: Crash when trying to change staff properties
Yes, this is the same, but it can even be reproduced easier:
1) "My First Score"
2) Right-click -> Stave (or Staff) Properties (which English version should be used?)
3) Ok or Apply
Best to use en_US, as those are the strings used/found inside the code
Another variant is #153411: Hiding clef or time signature causes crash
Still an issue, see #164141: musescore crashes on edit staff/change instrument
As shown by Jojo-Schmitz's stack trace, the problem is
unhandled id mag
and theabort
instruction at line 1247 of libmscore/staff.cppIndeed, handling of the property P_ID::MAG in Staff::setProperty was deleted by commit 337e885896
and it was moved to StaffTypeChange::setProperty
The change of property is called in by line 3313 of libmscore/undo.cpp
However, I don't know what should be done in this case, since I am not familiar with the changes Werner is implementing in the "core" objects.
There is no stack trace, just some debug output.
Outch! I missed that abort() instrunction! No wonder there's no stack trace.
Should have used a QFatal() rather than a QDebug() there?
Just deleting that abort() fixes the crash, I can't see any ill effect, except for the continued debug messages, but currently the code is in a pretty bad state, not much works.
That abort() got added in 6251397
Fixed in 6356d89
Automatically closed -- issue fixed for 2 weeks with no activity.
3 years later......
it is still fixed, isn't it?
Yes.