(Apple) BufferManager: out of buffers

[tresf]

This bug only affects master branch, and only the fork with MemoryManager.

The memory manger branch (#1088) compiles but crashes on Apple OS X Mavericks. The log is:

macmini:~ tresf$ /Applications/LMMS.app/Contents/MacOS/lmms 
VST sync support disabled in your configuration
Input device: 'HDMI' backend: 'Core Audio'
Output device: 'HDMI' backend: 'Core Audio'
Couldn't create MIDI-client, neither with ALSA nor with OSS. Will use dummy-MIDI-client.
BufferManager: out of buffers
Segmentation fault: 11

Backtrace: full

Process 83767 stopped
* thread #8: tid = 0xfe9ee, 0x00000001000153a1 lmms`BufferManager::acquire() + 49 at BufferManager.cpp:63, name = 'QThread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x00000001000153a1 lmms`BufferManager::acquire() + 49 at BufferManager.cpp:63
   60       }
   61       
   62       int i = s_availableIndex.fetchAndAddOrdered( -1 );
-> 63       sampleFrame * b = s_available[ i ];
   64       
   65       //qDebug( "acquired buffer: %p - index %d", b, i );
   66       return b;

[diizy]

Well that's weird. The BufferManager shouldn't run out of buffers in any kind of normal operation... it's currently capped at 512 buffers, which means that it should only run out if you have several hundreds of notes playing at the same time...

There's probably some sort of clang weirdness at play here. Is it possible for you to use GCC instead to compile on OSX?

[tresf]

Is it possible for you to use GCC instead to compile on OSX?

Definitely clang. I added the backtrace to the original report.

[tresf]

Is it possible for you to use GCC instead to compile on OSX?

Sorry, I misread that. No, gcc in it's unadulterated form is no longer an option for compiling LMMS on apple due to some namespace conflicts. It's actually the reason I can't get VST working, because winegcc is a wrapper for GCC and it has compatibility issues with Clang. gcc on Apple is just a symlink to llvm/Clang compiler.

I don't really know the technical reasoning why gnu gcc stopped working, but it had to do with a core library with the OS... so I'm sorry I cannot explain better, but when fixing stuff like the SWH plugins, it would have been much easier if I could have fallen back onto GCC rather than changing the code to be Clang compatible.

At the end of the day, Clang is open source (the llvm part), faster, stricter and runs better on Apple, so no regrets, but it certainly throws a wrench in the mix. 🚗

[tresf]

@diizy, can you explain in a bit more detail what is happening under the covers here:

-> 63       sampleFrame * b = s_available[ i ];

I've read up quite a bit on memory management for apple but they generally use examples that have built in memory functions, and without understanding c++ well enough, I'm not certain what function calls combined with known apple/clang compatibility I should research to help fix this. Any help understanding is greatly appreciated.

[diizy]

On 09/01/2014 07:47 AM, Tres Finocchiaro wrote:

@diizy https://github.com/diizy, can you explain in a bit more
detail what is happening under the covers here:

|-> 63 sampleFrame * b = s_available[ i ];
|
||
s_available is the array that holds pointers to the cached buffers. i is
the index, which is fetched from an atomic integer, which is atomically
fetched-and-decremented everytime a buffer is requested, so that the
array functions as a sort of lockless threadsafe stack.

Since writing a lockless threadsafe stack is really !"#¤!"#% hard, I
cheated a bit and made it so that released buffers get added to a
different vector, which gets added back to the main stack periodically
at a time when we can be sure that other threads can't mess around with
them (hence the refresh() function).

I've read up quite a bit on memory management for apple but they
generally used built in functions, and without understanding c++ well
enough, I'm not certain what native calls and apple compatibility I
should research to help fix this. Any help understanding is greatly
appreciated.

I've no idea, sorry.

[tresf]

Thanks I will research more. I can confirm now that master branch without memory manager does not crash. This crash is newly introduced with the memory manager branch only.

[tresf]

After further testing, I have reason to believe this is a bug with PortAudio as when I switch from Apple's CoreAudio to SDL, the software works. This also may be the reasoning behind the crashing in bug #1128 and I can confirm PortAudio crashes this branch on diizy/memmgr so as long as the Device drop-down is changed to something other than default.

I'm not sure if it is related, but master had some QT5 compat changes a few weeks ago which impacted the PortAudio code here: 4cee046

[tobydox]

2014-09-01 6:47 GMT+02:00 Tres Finocchiaro notifications@github.com:

@diizy https://github.com/diizy, can you explain in a bit more detail
what is happening under the covers here:

-> 63 sampleFrame * b = s_available[ i ];

I had the same bug yesterday when implementing the profiler. I finally
found the culprit (too late initialization of BufferManager) and already
sent a PR to diizy/memmgr. As soon as he accepts it, it should work on OS X
as well.

Toby

[tresf]

Thanks Toby! Confirmed as fixed. memmgr branch is now fixed on OSX. Closed per diizy#4.

P.S. Don't mind the version number in the screenshot as I hadn't bumped CMakeList.txt prior to building.