Crash when loading a new sound font (SF2 or SF3)

How much memory do you have available? There is no miracle, MuseScore will load the SF files in memory... If you go out of memory, it will crash!

it shouldn't crash but give an eror message and refuse to load that soundfont

Its a little known fact that (at least on unix systems like linux) programs which are low on memory simply crash.
Its a programmers myth that you ever get a zero pointer back from malloc() when the system is low on memory.
You alway get a valid pointer. The operating system checks on _access_ to this pointer for available memory. If there is
no available memory, it kills the program.
If you are a C/C++ programmer try yourself:

{syntaxhighlighter c}
#include <stdio.h>
#include

//---------------------------------------------------------
// main
//---------------------------------------------------------

int main(int argc, char* argv[])
{
for (int i = 0; true; ++i) {
printf("%d M\n", i / 256);
char* p = (char*)malloc(1024*4);
if (p == 0) {
printf("memory exhausted\n");
return 0;
}
*p = 0x22;
}
return 0;
}
{/syntaxhighlighter}

You will not get a "memory exhausted" but a "killed" message from the OS.

Unfortunately this whole discussion misses the point. Switching the soundfont did work in previous nightly builds. My last one was 5469d41. Now its not working neither in MuseScoreNightly-2013-07-16-1910-c513dd7.7z nor in MuseScoreNightly-2013-07-17-2008-721a479.7z.

i can load/delete sounfonts in current version without any problem (ubuntu)

Something has changed in the memory handling of soundfonts. By accident I had a rather large soundfont as my standard soundfont set in Musescore (Evanessence), which had been no problem in older nightly builds. Deleting this large soundfont or adding it with the current nightly build crashes Musescore on my Windows 7 64bit system. I don't think it's lack of memory because it did work w/o problems in older nightly builds on the same computer. (Working with smaller soundfonts such as the built-in Fluid seems to work - once I deleted the large one using an old nighlty build ;-)

Hi Werner

>Its a little known fact that (at least on unix systems like linux) programs which are low on memory simply crash.

a) this Report os about Windows
b) the behavoir you decribe is an idiosyncrasy of Linux, no other UNIX I ever worked with (and there were a few) did this 'Memory overcommit' stuff. For sure not any System V Release 4.x, DGUX, Irix

> Its a programmers myth that you ever get a zero pointer back from malloc() when the system is low on memory.
You alway get a valid pointer. The operating system checks on _access_ to this pointer for available memory. If there is
no available memory, it kills the program.

This is true for Linux and Linux only (I'm not sure about Mac)

> If you are a C/C++ programmer try yourself:
I am, or rather used to be, C-Programming on UNIX...

>You will not get a "memory exhausted" but a "killed" message from the OS.
On Linux and Linux only...

And even there it can get switched of, check http://jurjenbokma.com/ApprenticesNotes/turing_off_overcommit.html (turned up pretty much at the top of a http://lmgtfy.com/?q=linux+memory+overcommit, BTW: a similar search for Mac and Windows drew a blank)

I can reproduce the crash in my Windows 8 environment and latest Nightly 721a479.
I think it is a Windows specific bug: on the same machine no problem with the Linux (personal) build on Linux Mint 13.
Moreover, I think it is a Qt5.1-related bug: in a Qt4.8 old Nightly (fed5fb2) I see no problems.
I tried with the TimGM6mb.sf2 soundfont: sometimes it is added properly, but most of the time when I click "add" MuseScore crashes.

The crash happens at line 704 of fluid\fluid.cpp, inside function Fluid::addSoundFont:
mutex.unlock();
(checked with a personal debug build)

Indeed, no problem with 69bb4ac, the last Qt4 Version (I think), but crash with
721a479, the latest nightly build to date.
Both on the same machine, Windows 7 Enterprise, 3GB RAM

fixed with ef3be9a8 ?

no, not fixed i guess as i cannot reproduce this.
The commit tries to catch a memory overflow. This needs testing as its very hard on my machine to get an overflow (32GB + swap). A popup is also needed to tell the user that a soundfont could not be loaded (and possibly why).

Hmm, you can boot Linux with telling it to use only a certain amout of RAM, if I remember correctly

Ah, found it:
http://www.tldp.org/HOWTO/BootPrompt-HOWTO-3.html#ss3.3

It (6d1b64b) indeed still crashes

I can confirm ABL's comment. I got a crash on mac, loading a small soundfont. The error occured in Fluid::addSoundfont() -> QMutex::unlock() - >QBasicMutex::unlockInternal().
It could indeed be another Qt5 issue.

I tried with further experiments.
Here is the log of a gdb execution:
Breakpoint 1, FluidS::Fluid::addSoundFont (this=0x1b1663f8, Python Exception <class 'gdb.error'> cannot resolve overloaded method `data': no arguments supplied:s=) at C:\Git_packages\MuseScore\fluid\fluid.cpp:703
703 bool rv = (sfload(s, true) == -1) ? false : true;
(gdb) info locals
rv = false
(gdb) print mutex
$1 = { <QBasicMutex> = { d_ptr = { _q_value = 0x1 } }, <No data fields>}
(gdb) next
[New Thread 1556.0x15bc]
704 mutex.unlock();
(gdb) info locals
rv = true
(gdb) print mutex
$1 = { <QBasicMutex> = { d_ptr = { _q_value = 0x0 } }, <No data fields>}
according to this http://woboq.com/blog/internals-of-qmutex-in-qt5.html, if I understand correctly [but I may be horribly wrong :-) ], d_ptr is 1 when mutex is locked, therefore unlock gives an error if d_ptr is 0.
However, I checked and under Linux d_ptr of mutex in this case gives the same values (i.e. 1 before sfload(s,true) and 0 after), but there is no crash.
Here is the Linux log:
Breakpoint 1, FluidS::Fluid::addSoundFont (this=0x1c1c580, s=...)
at /home/antonio/MuseScore/fluid/fluid.cpp:703
703 bool rv = (sfload(s, true) == -1) ? false : true;
(gdb) info locals
rv = false
(gdb) print mutex
$8 = {<QBasicMutex> = {d_ptr = {_q_value = 0x1}}, <No data fields>}
(gdb) next
704 mutex.unlock();
(gdb) info locals
rv = true
(gdb) print mutex
$9 = {<QBasicMutex> = {d_ptr = {_q_value = 0x0}}, <No data fields>}

The difference between the two is that there is not the "[New Thread 1556.0x15bc]" before the unlock, otherwise they are identical.

Does all of this make sense to someone?

There is indeed a bug in the fluid mutex handling.
In process() the mutex is unlocked unconditional. This means that the mutex gets unlocked during sf loading which is a bad thing. I fixed this and hope it makes a difference...

Thank you Werner!
A first quick test in my build environment in Windows 8 shows that the commit fixes the issue.
Better to wait also a confirm in Mac [and maybe more test under Windows ;-) ] before setting this issue to fixed.

The nightly build for Windows corresponding to 770b64b is available now and does seem to fix the problem

I confirm the observation of Jojo Schmitz. It seems to work now again on Windows 7 64bit.

Let's mark it fixed then...

Automatically closed -- issue fixed for 2 weeks with no activity.