Easily reproducible from scratch.
With this file: test file.mscz , the three first measures works, but not the fourth (with 16th notes without beams) after adding a tremolo symbol "between notes", which leads to a crash.
Adding an `if (_chord1->beam())` at libmscore/tremolo.cpp, line 317
fixes the crash, but I have no idea about what unwanted side effects that might cause.
The 'offending' tremolo in 10_Epilog.mscz, measure 16 then looks like
That seems about right. Although I think instead of adding a check there, it might be better to replace the "_chord1->beams() > 0" with "_chord1->beam()" in line 314. That is, check for the existence of an actual beam at all rather than checking the nominal number of beams, and skip that entire section of code if there is no actual beam.
I'm not sure why `chord1->beams() returns something > 0 if there is no beam at all, maybe we should rather fix that? It actually returns `_durationtype.hooks()`, which really isn't the same thing, or is it?
Could be, but I see beams() being used in other places in the code and I would not want to change it without fully understanding the effect that would have everywhere else. Not unreasonable, as there actually aren't that many other usages. Still, I personally would be hesitant to change something on a global scale when there seems a much safer local fix.
Comments
See also https://musescore.org/en/node/73356, seems to be the same problem, at least it is the same stack trace:
0 Ms::Beam::beamDist beam.h 146 0xbd1f34
1 Ms::Tremolo::layout tremolo.cpp 317 0x8cf742
2 Ms::Chord::layoutStem chord.cpp 1501 0x821981
3 Ms::Score::doLayout layout.cpp 1515 0x80f3e7
4 Ms::Score::update cmd.cpp 175 0x7980f2
5 Ms::readScore file.cpp 2124 0x58ff8d
6 Ms::MuseScore::readScore file.cpp 328 0x581226
7 Ms::MuseScore::openScore file.cpp 309 0x5810f1
8 Ms::MuseScore::loadFiles file.cpp 290 0x580e92
9 Ms::MuseScore::cmd musescore.cpp 4059 0x494991
10 Ms::MuseScore::cmd musescore.cpp 3952 0x494206
11 Ms::MuseScore::qt_static_metacall moc_musescore.cpp 814 0x6a9fdd
12 ZN11QMetaObject8activateEP7QObjectiiPPv 0x68a655a2
13 ZN12QActionGroup7hoveredEP7QAction 0x61dc4b95
14 ?? 0x1e742f40
15 ZN7QAction8activateENS_11ActionEventE 0x61dc3b6e
16 ?? 0x28ca18
17 ?? 0x909001b9
18 ?? 0xf9b425ff
19 ?? 0x909001b8
...
Easily reproducible from scratch.
With this file: test file.mscz , the three first measures works, but not the fourth (with 16th notes without beams) after adding a tremolo symbol "between notes", which leads to a crash.
This issue occurs on June 27:
- This Nightly works: 79bf72e
- Not this one: 83ae627
So, it's a side effect of this commit: https://github.com/musescore/MuseScore/pull/2088
Adding an `if (_chord1->beam())` at libmscore/tremolo.cpp, line 317 fixes the crash, but I have no idea about what unwanted side effects that might cause.
The 'offending' tremolo in 10_Epilog.mscz, measure 16 then looks like
![tremolo.png]( "tremolo.png")
That seems about right. Although I think instead of adding a check there, it might be better to replace the "_chord1->beams() > 0" with "_chord1->beam()" in line 314. That is, check for the existence of an actual beam at all rather than checking the nominal number of beams, and skip that entire section of code if there is no actual beam.
I'm not sure why `chord1->beams() returns something > 0 if there is no beam at all, maybe we should rather fix that? It actually returns `_durationtype.hooks()`, which really isn't the same thing, or is it?
Could be, but I see beams() being used in other places in the code and I would not want to change it without fully understanding the effect that would have everywhere else. Not unreasonable, as there actually aren't that many other usages. Still, I personally would be hesitant to change something on a global scale when there seems a much safer local fix.
See https://github.com/musescore/MuseScore/pull/2166
merged in master 52adf6107e
Automatically closed -- issue fixed for 2 weeks with no activity.