Adding Instrument, after changing location in the Dialog, leads to crash
Reported version
3.x-dev
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
3.1-RC
In the attached file: wild slur.mscz
Open instruments (press i)
Add an instrument (I added a violin)
Click OK
Result: CRASH
Crash report being sent with this issue number.
This report was edited because I discovered it is not necessary to move the added instrument. Severity upgraded to blocker since I can't add any instrument. Will do further testing.
Fix version
3.1.0
Comments
The score leading to the crash was created using the Save as... command. I can't recreate the crash using a new empty score.
Not a general problem though, I can add instruments to scores
I agree, so severity should be reduced. I'm not sure what causes the crash though.
I can't reproduce this. Is that the right file? Are you using any non-default soundfonts?
Also, FYI - from the issue guidelines: "S1 - Blocker - The bug prevents a user from running/opening MuseScore."
I can reeproduce. Stack trace:
1 std::__atomic_base::load atomic_base.h 396 0xaed530
2 QAtomicOps::load qatomic_cxx11.h 227 0xaed530
3 QBasicAtomicInteger::load qbasicatomic.h 103 0xdcecf0
4 QtPrivate::RefCount::ref qrefcount.h 55 0xdb254f
5 QString::QString qstring.h 958 0xd84e4d
6 Ms::Channel::synti instrument.h 155 0xdd9268
7 Ms::MixerTrackPart::updateNameLabel mixertrackpart.cpp 173 0x530198
8 Ms::MixerTrackPart::MixerTrackPart mixertrackpart.cpp 102 0x52f99e
9 Ms::Mixer::updateTracks mixer.cpp 396 0x52af65
10 Ms::Mixer::setPlaybackScore mixer.cpp 319 0x52a9b8
11 Ms::Mixer::setScore mixer.cpp 331 0x52aa1f
12 Ms::MuseScore::instrumentChanged musescore.cpp 6415 0x4f8703
13 Ms::MuseScore::endCmd musescore.cpp 5835 0x4f57df
14 Ms::Score::endCmd cmd.cpp 189 0x98f3ca
15 Ms::MuseScore::editInstrList instrdialog.cpp 538 0x4acc70
16 Ms::MuseScore::cmd musescore.cpp 5917 0x4f5d5d
17 Ms::MuseScore::cmd musescore.cpp 5757 0x4f51d3
18 Ms::MuseScore::qt_static_metacall moc_musescore.cpp 855 0x40a306
19 ZN11QMetaObject8activateEP7QObjectiiPPv 0x68c81805
20 ZN12QActionGroup7hoveredEP7QAction 0x262e4ee5
...
I'm using a non-default soundfont...as usual.
soundfont is unrelated
Hmm. The stack trace shows the problem happens getting information from the synthesizer to display in the name label in the mixer. So, if not soundfont specifically, seems somehow related to the synthesizer.
I thought maybe from the trace I'd be able to reproduce by having the mixer open when executing the steps, but no such luck.
Hmmm, I'll see if I can reproduce.
Actually I'm using the HQ soundfont here, so it might be soundfont related
I did a typo above. The score was created using Save Selection... not Save as... also I'm not using the HQ soundfont, but when I switched to it I still got the crash.
And indeed, no crash when running without that HQ soundfont
So there you have your workaround ;-)
.
Oops, involuntary change about status
I was creating smaller score out of a larger score for a different issue. I decided to add a little bit more to it using copy and paste. When I tried to add the instrument, that's when it crashed. The whole score does not crash.
It's not related to the soundfont. I just switched to the MuseScore_General.sf3 and still got the crash. I've also gotten the crash with MuseScore_General_HQ.sf3 and AegeanSymphonicOrchestra-v2_2.sf2.
"The whole score does not crash"
It's already a first clue. So, useful to attach it.
SINFONIA VII.mscz
I didn't think of that being helpful. You are correct. The measure I initially saved was 224 of the second violin in case that's useful also.
In reply to [inline:SINFONIA VII.mscz] … by mike320
Selection problem? (with the minimal single measure) If, before first step (press "I"), you do Escape or simple click onto the score, or Ctrl + A, the problem no more longer exists.
I agree. If I do anything between opening the score and pressing i the crash doesn't happen, so this is the workaround. It should now be easier to trace down the crash and fix it.
Related to #289565: [Epic] 3.1-RC Regressions that must be fixed
Ok, I can reproduce now from scratch.
Steps:
1) New score for two instruments, say Flute and Oboe (test file: Flute Oboe.mscz )
2) Save/Exit/Reopen
3) Press "I" -> Click arrow up for toggling Oboe in top staff: Oboe UP.mscz
4) Save/Exit/Reopen
5) Press "I" -> Add an instrument, eg Violin -> Ok
Result: crash
(you notice that, as observed first, an action before entering in the dialog, step #5, eg Escape, allows to avoid the crash)
Ditto by keeping a single instrument, the one which had changed its location in the dialog: Oboe UP single.mscz
And so no issue if step #3 does not take place.
Confirmed. Looking at it.
Well, I got the crash described here when not running under the debugger, but not under the debugger. Any ideas?
In reply to Well, I got the crash… by Louis Cloete
The best debugger remains the human brain! :)
See https://github.com/musescore/MuseScore/pull/5060.
As mentioned in the pull request's description, this issue can also be reproduced before 3.1-RC (at least since 3.0.4 or 3.0.3 version) if one opens a Mixer window before executing steps 4-5 from this comment.
Fixed in branch master, commit f131df20b2
fix #289562: add missing blockSignals() calls on updating Mixer controls
Fixed in branch master, commit a0ed18ccac
_Merge pull request #5060 from dmitrio95/289562-add-instrument-crash
fix #289562: add missing blockSignals() calls on updating Mixer controls_
Automatically closed -- issue fixed for 2 weeks with no activity.