Loaded an XML file - was trying to adjust default file properties after doing some editing. I hit apply and boom!
Lost an hour of work!
Sigh
It seems to be quite easy to reproduce this issue, by the way. I’ve created a movie that demonstrates the steps. My apologies for the white rectangles around the outside - I did this without first closing windows of other programs with private information and it was just easier to redact the screen image appropriately.
Edit: your discourse is configured to prevent files greater than 4M from being uploaded and mine is 9M
Sorry!
I posted the video to my YouTube channel. Here’s the link so you can see how to reproduce the crash
This likely has to do with it being an xml import. The team is also likely going to want a diagnostic report file rather than a partial info dump.
Maybe — but when it’s the only way to get files in from Sibelius etc, not much hope to switch over to Dorico if it breaks before I’ve even done anything much with it.
You’re missing Romanos’s point. Without access to the diagnostics, and possibly the MusicXML file, there’s nothing for the developers to work with.
Right.
Sometimes there is odd or corrupted data in an xml file that causes issues. Dorico refines xml import/export with each major build, but they can’t control for weird cases like this that cause crashes unless you share full diagnostic files and often the xml files too, which can be shared with the dev team privately if necessary for copyright reasons.
I suppose I should add: there are many hundreds of us that have transferred thousands of MusicXML files from Sibelius to Dorico without significant errors (certainly without crashes). There’s something specific to your file that’s causing problems.
It may be a problem that’s known to Dorico’s developers, or it may be a new one. A YouTube video may be a helpful way for you to demonstrate that you have a problem, but it’s not helpful for getting the problem fixed.
No, I’m not — but without feedback from Dorico support, I have no idea what diagnostic information they want from me. As a developer myself, I generally want to start with at least two things:
-
A stacktrace that shows where the crash occurs - by matching that information with the symbol table information that they will have, the cause of the problem can often be immediately discovered.
-
A way to reproduce the problem so that if (1) above isn’t sufficient to determine the problem, there’s the possibility to recreate the situation within their development environment.
I provided both — should be a good start until someone gets back to me with whatever else they need.
Maybe, I don’t know — it was a simple file exported from Sibelius by a company that does transcriptions. Glad that hundreds have been successful – I have yet to have see decent results from importing an XML file into Dorico (and I’ve tried with various versions over the last few years) - heck, the lyrics didn’t even make it in.
Having now watched the video, there are a couple of traps you seem to be falling into:
- As per the procedure in the manual, hit Escape or Cmd/Ctrl-Enter when you’ve finished editing the text.
- You don’t need to do these one at a time - they’re governed by the Flow Headings editor in the right panel of Engrave mode. Go in there, double click on the Default Flow Heading and remove the flow number token. Apply and Close.
Your specific problem does not appear to be project-specific or related to MusicXML at all. If I start editing a flow heading and then try to switch layouts without exiting the text editor, I get the same crash.
I agree completely - I never thought it was - these were suggested by others
There is no question that I am a beginner with Dorico, having tried it in the past, given up and waited for the next version (several times) and so I’m just trying to find my way around it and do basic stuff.
Nevertheless, simply exploring, clicking on stuff and/or trying to navigate around the program (whether I’m doing it right or wrong) should not cause a crash
Thanks for reporting this problem, @gigperformer.
Normally a complete stack trace rather than just the first few frames in the main thread is helpful for us when trying to track down a crash, since the crash can be on another thread. The simplest way to provide such information to us in future, should you encounter another crash, is to choose Help > Create Diagnostic Report and to attach the resulting zip file to a message here.
I’m sorry for the inconvenience caused by this crash, which I confirm I can reproduce in Dorico 3.5.12. The good news, such as it is, is that it’s already fixed in our development builds for future versions.
1 Like
If you look at the stack trace that I posted, you’ll see that I did in fact explicitly post the thread that crashed. In this particular case, it was the main (GUI) thread that crashed. Interesting that you’re using the Qt framework, will make it easy to do a Linux version at some point 
And in fact, this is why I generally don’t report too much information the first time around as, until I hear back from support team I have no way to know whether it’s a known issue.
It seems silly to post complete stack traces and tons of debugging info if the problem has already been recognized.
Looking forward to the next build.