A stack trace is needed. First install debug symbols for the program
#debuginfo-install vmpk
Second: read the documentation https://fedoraproject.org/wiki/StackTraces
Third: post the stack trace for the crash.
Pianoteq is not available in Fedora 22. Please try to reproduce the crash using only open source programs available on Fedora repositories.
I've been unable to reproduce your problem using a virtual machine with Fedora 22 default installation, so there is something weird in your machine.
Last edit: Pedro Lopez-Cabanillas 2015-09-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No. I'm not closing this ticket. It will remain open and visible so if somebody else comes here searching for help, it can use it for reference of how to (and how not to) interact with this project, or any other open source project in similar circumstances.
First, some background: I don't earn any money when you install this program. And I don't ask for money in exchange for support like this ticket. I work on this for free in my spare time. I think that I may request some little collaboration from you in return, but if you think that it is excessive then please farewell and go somewhere else.
The level of collaboration I've asked is not something extraordinary or excessive. When Fedora compiles a program it is stripped of symbolic data which is needed when debugging some error or crash in the application. Fortunately, Fedora also saves this stripped data in complementary packages which can be installed when needed. These packages may be installed by hand using "dnf" (the Fedora replacement of the old "yum" utility) but you need to add manually the Fedora's debuginfo repositories and know the dependencies of the program, and finally the names of all the complementary packages. In order to ease the task and save users from all that work, Fedora also provides a wrapper script called "debuginfo-install", that in the past was wrapping "yum" commands and now in Fedora 22 it uses "dnf" commands internally. To use it you only need to install this little tool (for instance with dnf) and then (as root or sudo as usual) execute the script with the name of the application that you need to debug. The script will calculate dependencies and retrieve the appropriate packages from whatever repositories. This is all explained in the Fedora documentation: https://fedoraproject.org/wiki/StackTraces
End of the background. On other Linux distributions the procedure would be slightly different, but I know the mechanism for Fedora because I am myself a Fedora user. Of course VMPK is tested thoroughly in Fedora (and other popular Linux distributions). I've created yesterday a fresh virtual machine installing Fedora 22 from scratch, and also downloaded on it some closed source application called Pianoteq in order to reproduce the brief details given by the reporter. I couldn't reproduce the crash when closing the program. This is not unusual because there may be hundreds of programs running at the same time on the system, and thousands of packages installed on it. It would be impossible to guess the exact cause of the user's problem, but it is possible to analyze a stack trace and determine if it was caused by a bug in the program or caused by some other circumstances. In the first case it will lead to a fix that would benefit all users. And if not, at least we may find a workaround.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A stack trace is needed. First install debug symbols for the program
#debuginfo-install vmpk
Second: read the documentation
https://fedoraproject.org/wiki/StackTraces
Third: post the stack trace for the crash.
Pianoteq is not available in Fedora 22. Please try to reproduce the crash using only open source programs available on Fedora repositories.
I've been unable to reproduce your problem using a virtual machine with Fedora 22 default installation, so there is something weird in your machine.
Last edit: Pedro Lopez-Cabanillas 2015-09-10
OK. Thanks... but no thanks.
I'm using dnf to install. dump is inhibited. I'm not a Linux geek.
I'll find an alternative. Please close the bug.
regards Dave
No. I'm not closing this ticket. It will remain open and visible so if somebody else comes here searching for help, it can use it for reference of how to (and how not to) interact with this project, or any other open source project in similar circumstances.
First, some background: I don't earn any money when you install this program. And I don't ask for money in exchange for support like this ticket. I work on this for free in my spare time. I think that I may request some little collaboration from you in return, but if you think that it is excessive then please farewell and go somewhere else.
The level of collaboration I've asked is not something extraordinary or excessive. When Fedora compiles a program it is stripped of symbolic data which is needed when debugging some error or crash in the application. Fortunately, Fedora also saves this stripped data in complementary packages which can be installed when needed. These packages may be installed by hand using "dnf" (the Fedora replacement of the old "yum" utility) but you need to add manually the Fedora's debuginfo repositories and know the dependencies of the program, and finally the names of all the complementary packages. In order to ease the task and save users from all that work, Fedora also provides a wrapper script called "debuginfo-install", that in the past was wrapping "yum" commands and now in Fedora 22 it uses "dnf" commands internally. To use it you only need to install this little tool (for instance with dnf) and then (as root or sudo as usual) execute the script with the name of the application that you need to debug. The script will calculate dependencies and retrieve the appropriate packages from whatever repositories. This is all explained in the Fedora documentation: https://fedoraproject.org/wiki/StackTraces
End of the background. On other Linux distributions the procedure would be slightly different, but I know the mechanism for Fedora because I am myself a Fedora user. Of course VMPK is tested thoroughly in Fedora (and other popular Linux distributions). I've created yesterday a fresh virtual machine installing Fedora 22 from scratch, and also downloaded on it some closed source application called Pianoteq in order to reproduce the brief details given by the reporter. I couldn't reproduce the crash when closing the program. This is not unusual because there may be hundreds of programs running at the same time on the system, and thousands of packages installed on it. It would be impossible to guess the exact cause of the user's problem, but it is possible to analyze a stack trace and determine if it was caused by a bug in the program or caused by some other circumstances. In the first case it will lead to a fix that would benefit all users. And if not, at least we may find a workaround.
The bug (ticket #28) was identified and solved thanks to other Mac users. Now it is fixed and the new release 0.6.2 should be OK with it.