Linux, Codeblocks, ofSoundPlayer and corrupted double-linked list


Firstly, thank you for a great framework!

However I have come across what appears to be a bug in the ofSoundPlayer module.

When I close an Openframeworks app that implements the ofSoundPlayer class, the application hangs with the following message:

*** Error in '<ofApp executable here>': corrupted double-linked list: <long hex value here> ***

I can recreate this error message creating a blank project using project generator and add the following line into ofApp.h (in the ofApp class):

ofSoundPlayer test;

I compile and run this simple test program and than hit Esc to close the program down. The window closes but the debug console hangs with the above error message.

I am developing on a ubuntu 14.04 (64 bit) machine with codeblocks. I have tested my app with openframework versions 0.8.3 and 0.8.4.

After doing some digging, I believe this error message occurs when the application attempts to deconstruct the static set<ofOpenALSoundPlayer*> players; in ofOpenALSoundPlayer.cpp.

I haven’t been able to discover a solution to resolve this error.

Does anyone else experience this problem? Does anyone have advice on how I might be able to resolve this issue?


Hi again,

Just wanted to ask, has anyone come across this before?

I haven’t come across a solution yet. The only way I have been able to terminate apps is by using a kill -9 command to kill the apps process.

Any comments will be appreciated!


I have the same problem! Also I don’t hear any sound when playing a sound… I am also developping with ubuntu 14.04 and with a osx 10.10 and I don’t have any problem with the mac.


Thanks for the reply fabiaserra. Its nice to know that I am not the only one experiencing this issue.

FYI, if I force my application to use the FMOD sound back-end, I get no errors. This error only seems to come up when using the OpenAL back-end.

Any further help will be greatly appreciated!!!

1 Like

Thanks GTM! I will try it out tomorrow with the Linux computer but how do you force the application to use FMOD instead? :blush:

You can force the application to use FMOD by adding the following line into your code:


I tried to put this code in the top line of my main.cpp file, but for some reason it did not work for me. So I put it in the top line of the ofApp.h file, which worked.

You can further ensure that you are using the FMOD back-end by using the ofFmodSoundPlayer instead of ofSoundPlayer. Both ofFmodSoundPlayer and ofSoundPlayer inherit the same base class so all the normal functions for ofSoundPlayer should also work for ofFmodSoundPlayer. However using the above define should force ofSoundPlayer to use the same code as ofFmodSoundPlayer.

Beware that there are licencing caveats with FMOD (and I guess with OpenAL) so make sure you do your research before putting your code into production.

For all those interested, I have made some further progress in my problem. The problem line of code is line 126 of ofOpenALSoundPlayer.cpp. (Version 0.8.4). This line erases the ofOpenALSoundPlayer pointer from a global std::set.

I suspect that the erase call is corrupting the std::set for some reason. I can not figure out why and it is very frustrating.

This line could also be releasing the memory that is tied to the ofOpenALSoundPlayer object that it pointers to, which causes the software to try and release the same bit of memory twice and corrupts the memory. From my research, this shouldn’t be happening, but it might be.

In any case, I feel like is might be a bug in the gcc compiler and not a bug in open frameworks. But I would be awesome if someone can confirm that.

If you comment out line 126 of ofOpenALSoundPlayer.cpp, it fixes the issues. However this is a little bit hacky and in some cases may break the Spectrum Analysis components of the code. So if your application is using the Spectrum analysis functions at all, I would not recommend implementing this change.

Again if anyone is experiencing the same problem, I would be great to hear from you!