Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(Apple) BufferManager: out of buffers #1114

Closed
tresf opened this issue Aug 29, 2014 · 9 comments
Closed

(Apple) BufferManager: out of buffers #1114

tresf opened this issue Aug 29, 2014 · 9 comments

Comments

@tresf
Copy link
Member

tresf commented Aug 29, 2014

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
Copy link
Contributor

diizy commented Aug 29, 2014

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
Copy link
Member Author

tresf commented Aug 29, 2014

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

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

@tresf
Copy link
Member Author

tresf commented Aug 29, 2014

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
Copy link
Member Author

tresf commented Sep 1, 2014

@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
Copy link
Contributor

diizy commented Sep 1, 2014

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
Copy link
Member Author

tresf commented Sep 1, 2014

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
Copy link
Member Author

tresf commented Sep 3, 2014

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
Copy link
Member

tobydox commented Sep 3, 2014

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
Copy link
Member Author

tresf commented Sep 3, 2014

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.
image

@tresf tresf closed this as completed Sep 3, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants