Pasting nested tuplet onto linked staff causes crash
1. Open attached score (produced in 2.0).
2. Click on either stave with notes (selecting them).
3. 'Edit'>'Copy'.
4. Click on either empty stave.
5. 'Paste'.
Result: Crash.
Note: See attached log.
Using MuseScore 2.0 Nightly Build 2e61d6b - Mac 10.7.5.
| Attachment | Size |
|---|---|
| Pasting causes crash.mscz | 2.08 KB |
| Pasting causes crash [Log].txt | 62.61 KB |
Comments
The issue will be deeper than the title suggests.
Issue at hand seems to be that a paste of a nested tuplet into a linked staff crashes.
The "deeper" part, I guess, is that even creating a nested tuplet from scratch in linked staves doesn't work so well - adding the inner tuplet messes up the outer one. It seems it is not being properly linked, which is also probably what leads to the crash.
See this: #31936: Nested tuplet doesn't appear correctly in linked stave
It could all fall under the same problem?
Yes, I assume it's the same thing. Doesn't hurt to have separate reports. We will just have to remember to close the other manually if it turns out the same commit fixes both problems, which I suspect will be the case.
I probably would have done them altogether, but the first report was reproduced at an earlier stage and with less information for me to go on.
I'm getting crashes pasting simple non-nested tuplets from one file to another. I have tested with the latest nightly build and it also has the same issue as 2.0 Beta 1. Should I open up a new ticket with more details or do you think it's related to this one? If so, would you need me to describe in more details here? Thanks!
Hi tamajochi
It depends if the log is the same, but from what you describe, I would create another issue - post as much detail as possible (including an attached log).
Actually, FWIW, logs are not worth providing unless you can't provide steps to reproduce the problem. Steps to reproduce the problem are *always* better. Then we can run it under the debugger ourselves, and that will tell us everything the log would have and far more besides.
So I'd only go to the trouble of providing a if you *don't* have steps to reproduce - and even then, it's kind of a crapshoot as to whether the log will be of any value. Also, being even pickier, If you do provide a log, I personally would prefer them to be added as an attachment rather than pasted into the report itself, otherwise it makes the issue very hard to read.
Of course the steps are important - the log is supplementary, but seemingly beneficial (having been asked to post them previously), and yes, such a log is definitely better as an attachment (e.g. .txt) as it makes the issue tidier.
Did you mean "...unless you *can* provide steps to reproduce the problem."?
tamajochi didn't mention a lack of steps, hence my suggestion.
No, I mean logs are normally only beneficial to a developer if they cannot reproduce the problem themselves - that is, if the person reporting the problem *cannot* produce steps to reproduce. If a developer can reproduce the problem, then the log provides no additional information whatsoever - reproducing the problem under the debugger will show the exact same information and a *ton* more besides, in a far more useful (interactive) format. If someone can reproduce the problem under the debugger then the log is completely superfluous. It's is the developer *cannot* reproduce the problem under the debugger that the log *might* possibly provide a clue.
So if you were ever asked to provide a log, I'm assuming it was a case where you did *not* have steps to reproduce (or perhaps, where those steps didn't work to reproduce the problem for someone else).
That said, it can be a quick way to tell at a glance if two separate bug reports might be related without going through the trouble of actually following both sets of steps - but even so, one would eventually want to actually run the steps to be sure.
Anyhow, I mention this because I don't want anyone discouraged from submitting a support because they don't how how to obtain a log (it's by no means easy/obvious to most people, except maybe on Mac), or being misled into thinking once they gone to the trouble of getting the log, they've done what they need to do. Whatever time one spends getting and posting the log can virtually always be better spent producing a better report. If one if going to spend a given amount of time submitting a bug report, I'd rather they spend all of that time writing up the description of the problem and steps to reproduce, rather than spending only half as long on that and the rest figuring out how to generate and post a log.
Well, this has sparked quite the conversation. I've been doing some more testing and it doesn't seem to be related to tuplets after all. If I copy and paste just the bars with the tuplets, MS does not crash so I'm not sure what is causing the problem. I'll open up a new ticket with as much info as possible. Thanks!
because they don't how how to obtain a log
Is there a resource that explains how to? I've looked around here but couldn't find anything. This way I can add it to the ticket I opened. Thanks.
Details of how to get a crash log depend on what OS you are on. You could do a Google search for your particular OS to learn more (eg, "application crash log Windows 8" or whatever). But since you have good steps to reproduce, there is no added value in a log, so you could wait until you encountered a crash you *can't* reproduce before bothering with looking up how.
Right, thanks for the help.
FWIW, if anyone reads this, logs are accessible in Windows 7 as follows: Click Start Button --> Type "Event" --> Click on "Event Viewer". Then in the Windows Event Viewer, crash logs are under "Windows Logs" --> "Application".
3bb8208dd8
Automatically closed -- issue fixed for 2 weeks with no activity.