[Mac] Crash on startup while loading SF3 soundfont

If I have trouble with crashes on startup, or loading a score, etc, I think I start it via Terminal without sound, remove SF3 from the Synthesiser and 'Store'.

I can load SF2 after that, although I have problems with the sound quality.

Sometimes, the program will crash a few times before I can finally open it.

If this may be of help, here is a more complete log of the crash obtained by running Mac debug version under gdb.
The crash seems to happen at line 162 of fluid/sfont3.cpp.

I tried to launch Guard Malloc together with gdb on a Mac debug compile and it first found a problem at line 281 of synthesizer/msynthesizer.cpp:
memset(effect1Buffer, 0, n * sizeof(float) * 2);

Here is the result:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000001de115000
[Switching to process 217 thread 0xb403]
0x00007fff9539dc50 in bzero$VARIANT$sse2 ()
(gdb) bt
#0 0x00007fff9539dc50 in bzero$VARIANT$sse2 ()
#1 0x00000001008396b7 in Ms::MasterSynthesizer::process (this=0x1de10cf70, n=4752, p=0x1dddd1b80) at /Users/antonio/MuseScore/synthesizer/msynthesizer.cpp:281
#2 0x00000001001e015f in Ms::Seq::process (this=0x1d9749f00, n=4752, buffer=0x1dddd1b80) at /Users/antonio/MuseScore/mscore/seq.cpp:671
#3 0x00000001004aa2c0 in Ms::paCallback (out=0x1dddd1b80, frames=4752) at /Users/antonio/MuseScore/mscore/pa.cpp:47
#4 0x00000001052e54c3 in Pa_GetSampleSize ()
#5 0x00000001052e46a6 in Pa_GetSampleSize ()
#6 0x00000001052e9ef8 in PaMacCore_Initialize ()
#7 0x00000001dd902867 in AUInputElement::PullInput ()
#8 0x00000001dd901f30 in AUInputFormatConverter2::InputProc ()
#9 0x00007fff9030adc9 in AudioConverterChain::CallInputProc ()
#10 0x00007fff9030aaec in AudioConverterChain::FillBufferFromInputProc ()
#11 0x00007fff9030aa7a in BufferedAudioConverter::GetInputBytes ()
#12 0x00007fff9030c92e in Resampler2Wrapper::RenderOutput ()
#13 0x00007fff9030a718 in BufferedAudioConverter::FillBuffer ()
#14 0x00007fff9030a881 in AudioConverterChain::RenderOutput ()
#15 0x00007fff9030a718 in BufferedAudioConverter::FillBuffer ()
#16 0x00007fff9030a380 in AudioConverterFillComplexBuffer ()
#17 0x00000001dd901e44 in AUInputFormatConverter2::PullAndConvertInput ()
#18 0x00000001dd901ab6 in AUConverterBase::RenderBus ()
#19 0x00000001dd8ff551 in AUBase::DoRenderBus ()
#20 0x00000001dd8fdc9d in AUBase::DoRender ()
#21 0x00000001dd904d61 in AUHAL::AUIOProc ()
#22 0x00007fff94647d8f in HALC_ProxyIOContext::IOWorkLoop ()
#23 0x00007fff94647391 in HALC_ProxyIOContext::IOThreadEntry ()
#24 0x00007fff9464724b in HALB_IOThread::Entry ()
#25 0x00007fff953b0742 in _pthread_start ()
#26 0x00007fff9539d181 in thread_start ()
(gdb) up
#1 0x00000001008396b7 in Ms::MasterSynthesizer::process (this=0x1de10cf70, n=4752, p=0x1dddd1b80) at /Users/antonio/MuseScore/synthesizer/msynthesizer.cpp:281
281 memset(effect1Buffer, 0, n * sizeof(float) * 2);
(gdb) print effect1Buffer
$1 = {0 <repeats 4096 times>}
(gdb) print sizeof(float)
$2 = 4
(gdb) print n
$3 = 4752
(gdb) print sizeof(effect1Buffer)
$4 = 16384

If I understand correctly, memset is trying to put in effect1Buffer, which is 16384 bit long, a series of zeroes with length 4752*4*2 = 38016 bit.

Under Windows 8, a build of the same MuseScore revision (but 32bit build under Windows) gives:
Breakpoint 1, Ms::MasterSynthesizer::process (this=0x148841f8, n=1024, p=0x10484f80)
at C:\Git_packages\MuseScore\synthesizer\msynthesizer.cpp:281
281 memset(effect1Buffer, 0, n * sizeof(float) * 2);
(gdb) print n
$1 = 1024
(gdb) print sizeof(float)
$2 = 4
(gdb) print effect1Buffer
$3 = {0 <repeats 4096 times>}
(gdb) print sizeof(effect1Buffer)
$4 = 16384

So in 16384 bit-length effect1Buffer it is putting 1024*4*2=8192 bits, which seems more reasonable than what is happening in Mac.

Could this be the problem affecting Mac builds?
Where does n, the number of frames, come from? Why is it 4752 under Mac?

The tests were performed with Mac OS X 10.8.2 (VirtualBox) and revision a4bab21d

> This is probably already a good catch even if I don't think it's the same problem
> than the crash when loading the soundfont.

Indeed, I tried to increase the size of effect1Buffer and still the execution of mscore stopped at decrompressOggVorbis.
It stopped at line 17:
short* oPtr = odata;

If I put a breakpoint at this line, run again and try to print the variable odata, I obtain:
(gdb) print odata
Cannot access memory at address 0x111185c80
(gdb) print &odata
$1 = (short (*)[512000]) 0x111185c80

With (almost) the same conditions, the Windows build prints the value of the variable (which I think at this point is simply full of junk bytes):
(gdb) print odata
$1 = {0 <repeats 511080 times>, -920, 6794, 0, 0, 4280, 30506, 0 <repeats 60 times>, 192, 4190, 0, 0, 608, 4190, 17,
4352, 16018, 0, -3248, 6794, 7372, 30637, 0, 4190, -4256, 4190, 21, 0, 608, 4190, 21, 0, 0, 4190, -3208, 6794,
7287, 30637, 0, 4190, -22360, 4994, -22368, 4994, 0, 4190, 192, 4190, 0, 0, 20408, 4190, 173, -21248, 2047, 0,
-3172, 6794, 7353, 30637, 0, 4190, -17928, 4190, 14994, 0, 20408, 4190, 14994, 0, 0, 4190, -3132, 6794, 192, 4190,
0, 0, 20408, 4190, 17, 4352, 14994, 0, -3116, 6794, 7372, 30637, 0, 4190, -4256, 4190, 45, 0, 20408, 4190, 45, 0,
0, 4190, -3076, 6794, 7287, 30637, 0, 4190, -16904, 4190, -16912, 4190, 0, 4190, -3040, 6794, 23107, 30637, 0,
4190, 45, 0, 7166, 30637, -16904, 4190, 45, 0, 45, 0, 128, 0, -17936, 4190, 0, 4190, -16552, 4190, 0, 0, -2860,
6794, 1024, 0, 0, 4190, -17936, 4190, -2860, 6794, 22767, 30637, 22814, 30637, -12324, -31503, 0, 0, 0, 4190, 1016,
0, 45, 0, -17936, 4190, -17928, 4190, 192, 4190, 19280, 4999, 0, 4190, 0, 0, 1, 0, 9, 4191, 20408, 4190, 173, 0...}
(gdb) print &odata
$2 = (short (*)[512000]) 0x1a7b59c8

Could this be the source of the crash? Why can't gdb access the variable?

I know very very little about C and C++, so please forgive me if I am wrong in the following.
I searched some information with Google and, if I understood correctly what they say, odata in this case is allocated in the "stack", is it correct?
Is the stack large enough to hold this variable? I found that pthread implementation on Mac has a 512kB stack (http://developer.apple.com/library/mac/#qa/qa1419/_index.html), is MuseScore using this implementation?

On the system I am testing the builds it says the same(ulimit -s gives 8192), but I still think it is a problem of the dimension of the stack.
When I change MAX_OUT (line 15 of fluid/sfont3.cpp) to values 1024*200, compile and run under gdb, gdb can display odata, as in the Windows version; there is a crash later in the file because odata is not big enough to hold all the data in this case and the crash happens at line 164.
For MAX_OUT larger than 1024*300 gdb can't access odata.
At MAX_OUT equal to 1024*250 odata seems to behave properly, but I get a kern protection failure at line 123.
(I didn't try values between 1024*250 and 1024*300)
If I put MAX_OUT to 1024*240 I see no more crashes (I had also put MAX_BUFFERSIZE to 16384, just in case).

Therefore I strongly fear that the stack size used by MuseScore in Mac is, at least in this case, limited at 512 kB (or similar). Is it possible to increase this space?
Alternatively (and here please forgive my lack of knowledge of C++), is it necessary to put odata in the stack? Can it be put in the heap?

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