Double-clicking a soundfont file (.SF2 or .SF3) opens MuseScore 2.0 Beta 2, with a dialog box asking if I wish to install the soundfont. If I click "No," the application instantly crashes.
I just figured out another element of the issue: it only happens if the application is not currently running. Possibly you'll be able to reproduce it if you make sure to quit MuseScore 2.0 before you double-click the soundfont.
No, that was what I did in the first place. Could also relate to some option settings that affect startup, or even something about one of your recently-accessed scores that Startcenter is trying to display a thumbnail of.
I don't really know how to read a Mac crash log, but at a glance, it seems to show the crash occurs with the basic Qt event loop and has nothing to do with MuseScore itself unelss maybe we corrupted memory somehow.
I also kind of wonder if maybe something is wrong with your installation. Elsehwerre you mentioned seeing a dialog prompting you to find an MP3 library, but I've never heard of anyone else need to do that before - makes me wonder if somehow your installation is faulty. But this too could be some sort of OS dependency.
Well, I just deleted the application and its associated files on my computer and downloaded it fresh. Tried it again, it happened just the same.
As to the matter of the MP3 library, that didn't surprise me at all. Open-source multi-platform audio editing software Audacity does the exact same thing, only they provide a link to download LAME the first time as well as the option to locate it. (The difference is that then it works to export MP3s, of course…)
I might point out that the "Yes/No" dialog box asking if you want to install the soundfont opens up behind the start center, so you might not see it at first, but I'm guessing you got past that okay.
Is there nobody else with a Mac OS X 10.9.5 computer to confirm this?
I'm not sure, I don't see anything particularly useful in the crash log. But unless I am misunderstanding something, this crash is relatively minor in significance, right? I mean, it only happens if you attempt to start MuseScore up a particular way and then change your mind and decide you didn't want to start it that way after all. Normal startup is fine, adding soundfonts the normal way is fine, etc - it's very unlikely any user would actually run into this, correct? And even if you do, the fact that it happens on startup means you are guaranteed to not lose data in the process, and there is a very easy workaround - don't double click soundfonts and then change your mind :-)
BTW, a couple of questions that may turn out to be useful:
- what is the exact text of the message displayed in the dialog - in particular, does it contain the full path name of the file you are trying to install, just the file name, or neither?
- are you presisng the No button, hitting Esc, or using some other method to decline?
And it doesn't matter whether you click "No," close the dialog window, or hit the Escape key. Same effect.
And you're of course right that it's fine if this goes unfixed. Except the idea of deciding to let a bug that causes a crash (critical!) go unfixed really bothers me. Why would you do that?
Let's downgrade it to major then. This is what we invented that priority for.
That isn't to say that it should not get fixed, just that other issues are more important...
BTW, I've just checked, same dialog under Windows, but no crash if you click 'no'
All right. I actually originally doubted this bug was critical myself.
Not this is of any relevance or importance, but am I right that "same dialog under Windows" means that even the shape and color of the Yes/No buttons is the same?
Whoa whoa whoa! Windows style? Of course? How is that possible? I was just being told that in MuseScore 2.0 it was decided to have a single unified appearance across all platforms, and that it was not possible to match native system styles anymore. See http://musescore.org/en/node/42091 and http://musescore.org/en/node/21875#comment-98406 . What game are you people playing here? That dialog I uploaded a screenshot of sure as heck wasn't Mac style.
The style of window *decorations* should follow the OS; the style of the *contents* of the window should be using the MsueScore builn-in style. That's my understanding, anyhow, and it matches what I see. No games, jsut perhaps a slight misunderstanding.
Anyhow, we'll fix the actual bug here if we can of course. It's just that until someone with access to debugging tools can reproduce it, it's entirely possible it *can't* be fixed, and we may have to decide to live with it. given that it appearnetly affects only a subset of users, and only when doing something unusual that would be easy to avoid, and comes with no consequences in terms of potential for lost data, it would be an easy crash to lvie with, as crashes go. But still, if we can ever reproduce it, we'll certainly try to fix it!
Okay, perhaps I wasn't clear enough when I asked Jojo-Schmitz whether "the shape and color of the Yes/No buttons [was] the same", and he might have misunderstood when he answered "no, they are Windows style, of course." So let me ask just this question, as specifically as I can:
When that dialog box, or any dialog in MuseScore 2.0 for that matter, is displayed in the Windows version, do those Yes/No buttons look the same as the screenshot I uploaded, or do they look like such buttons typically do in that operating system?
Or can somebody show me a screenshot of a MuseScore dialog in Windows, so as to be absolutely sure? Thanks.
On my Windows 7 system they look just like your screenshot, as is the case on my Ubuntu system. It's also clear it should be so from the code and from numerous discussions over the past couple of years.
Comments
Hi
Thanks for the report.
Which operating system are you using?
This was in Mac OS X 10.9 Mavericks. Are you sure this bug is critical? Let's put it at major and call it even.
Apologies. You're right, it counts as critical according to http://musescore.org/en/developers-handbook/how-write-good-bug-report-s… .
Hi again
I can't reproduce - maybe it's OS-specific?
Using MuseScore 2.0 beta 2 - Mac 10.7.5.
Could you upload the crash log as a .txt file?
Here it is.
I can't reproduce either, Ubuntu 14.04.
I just figured out another element of the issue: it only happens if the application is not currently running. Possibly you'll be able to reproduce it if you make sure to quit MuseScore 2.0 before you double-click the soundfont.
No, that was what I did in the first place. Could also relate to some option settings that affect startup, or even something about one of your recently-accessed scores that Startcenter is trying to display a thumbnail of.
Well, I have no idea. Does the crash log mean I uploaded mean anything to you?
I don't really know how to read a Mac crash log, but at a glance, it seems to show the crash occurs with the basic Qt event loop and has nothing to do with MuseScore itself unelss maybe we corrupted memory somehow.
I also kind of wonder if maybe something is wrong with your installation. Elsehwerre you mentioned seeing a dialog prompting you to find an MP3 library, but I've never heard of anyone else need to do that before - makes me wonder if somehow your installation is faulty. But this too could be some sort of OS dependency.
Well, I just deleted the application and its associated files on my computer and downloaded it fresh. Tried it again, it happened just the same.
As to the matter of the MP3 library, that didn't surprise me at all. Open-source multi-platform audio editing software Audacity does the exact same thing, only they provide a link to download LAME the first time as well as the option to locate it. (The difference is that then it works to export MP3s, of course…)
I might point out that the "Yes/No" dialog box asking if you want to install the soundfont opens up behind the start center, so you might not see it at first, but I'm guessing you got past that okay.
Is there nobody else with a Mac OS X 10.9.5 computer to confirm this?
I can reproduce.
I don't have 10.8 to test.
Using MuseScore 2.0 Beta 2 - Mac 10.10.1.
At last! Can I assume that this will now be fixed soon?
I'm not sure, I don't see anything particularly useful in the crash log. But unless I am misunderstanding something, this crash is relatively minor in significance, right? I mean, it only happens if you attempt to start MuseScore up a particular way and then change your mind and decide you didn't want to start it that way after all. Normal startup is fine, adding soundfonts the normal way is fine, etc - it's very unlikely any user would actually run into this, correct? And even if you do, the fact that it happens on startup means you are guaranteed to not lose data in the process, and there is a very easy workaround - don't double click soundfonts and then change your mind :-)
Or am I missing something here?
BTW, a couple of questions that may turn out to be useful:
- what is the exact text of the message displayed in the dialog - in particular, does it contain the full path name of the file you are trying to install, just the file name, or neither?
- are you presisng the No button, hitting Esc, or using some other method to decline?
The dialog looks like this:
And it doesn't matter whether you click "No," close the dialog window, or hit the Escape key. Same effect.
And you're of course right that it's fine if this goes unfixed. Except the idea of deciding to let a bug that causes a crash (critical!) go unfixed really bothers me. Why would you do that?
Let's downgrade it to major then. This is what we invented that priority for.
That isn't to say that it should not get fixed, just that other issues are more important...
BTW, I've just checked, same dialog under Windows, but no crash if you click 'no'
All right. I actually originally doubted this bug was critical myself.
Not this is of any relevance or importance, but am I right that "same dialog under Windows" means that even the shape and color of the Yes/No buttons is the same?
no, they are Windows style, of course
Whoa whoa whoa! Windows style? Of course? How is that possible? I was just being told that in MuseScore 2.0 it was decided to have a single unified appearance across all platforms, and that it was not possible to match native system styles anymore. See http://musescore.org/en/node/42091 and http://musescore.org/en/node/21875#comment-98406 . What game are you people playing here? That dialog I uploaded a screenshot of sure as heck wasn't Mac style.
The style of window *decorations* should follow the OS; the style of the *contents* of the window should be using the MsueScore builn-in style. That's my understanding, anyhow, and it matches what I see. No games, jsut perhaps a slight misunderstanding.
Anyhow, we'll fix the actual bug here if we can of course. It's just that until someone with access to debugging tools can reproduce it, it's entirely possible it *can't* be fixed, and we may have to decide to live with it. given that it appearnetly affects only a subset of users, and only when doing something unusual that would be easy to avoid, and comes with no consequences in terms of potential for lost data, it would be an easy crash to lvie with, as crashes go. But still, if we can ever reproduce it, we'll certainly try to fix it!
Okay, perhaps I wasn't clear enough when I asked Jojo-Schmitz whether "the shape and color of the Yes/No buttons [was] the same", and he might have misunderstood when he answered "no, they are Windows style, of course." So let me ask just this question, as specifically as I can:
When that dialog box, or any dialog in MuseScore 2.0 for that matter, is displayed in the Windows version, do those Yes/No buttons look the same as the screenshot I uploaded, or do they look like such buttons typically do in that operating system?
Or can somebody show me a screenshot of a MuseScore dialog in Windows, so as to be absolutely sure? Thanks.
On my Windows 7 system they look just like your screenshot, as is the case on my Ubuntu system. It's also clear it should be so from the code and from numerous discussions over the past couple of years.
Should be fixed in 1e2596b4f1 together with #40051: Start Centre shown when opening application via file
Fix confirmed.
Automatically closed -- issue fixed for 2 weeks with no activity.