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

The OpenAL-Soft version shipped with SFML is buggy #900

Closed
mantognini opened this Issue May 28, 2015 · 7 comments

Comments

Projects
None yet
4 participants
@mantognini
Member

mantognini commented May 28, 2015

As stated in this thread, commit ce16554, introduced to fix OpenAL thread safety (#541 & #831), actually breaks other parts of the audio module.

I won't be able to solve this before 2.3.1 so I'm wondering if you should temporarily revert this commit and propose a properly fixed version in 2.3.2 (for example). Thoughts?

SSCCE

#include <SFML/Audio.hpp>

using namespace sf;

int main(int argc, char const** argv)
{
    if (!SoundBufferRecorder::isAvailable()) {
        return EXIT_FAILURE;
    }

    sf::SoundBufferRecorder recorder;

    recorder.start();

    recorder.stop();

    return EXIT_SUCCESS;
}

Trace

0   libsystem_c.dylib               0x00007fff91c7c152 strlen + 18
1   org.sfml-dev.OpenAL             0x0000000101da3a8c al_string_copy_cstr + 28
2   org.sfml-dev.OpenAL             0x0000000101db21b3 ca_open_capture + 2115
3   org.sfml-dev.OpenAL             0x0000000101d9451b alcCaptureOpenDevice + 587
4   libsfml-audio.2.3.dylib         0x0000000101d3ac98 sf::SoundRecorder::start(unsigned int) + 296
5   sound-capture                   0x0000000101d2c894 main + 228
6   libdyld.dylib                   0x00007fff917c95c9 start + 1
@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch May 28, 2015

Member

Does this happen with OS X only? Is the bug in OpenAL-Soft or in SFML?

Member

MarioLiebisch commented May 28, 2015

Does this happen with OS X only? Is the bug in OpenAL-Soft or in SFML?

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini May 28, 2015

Member

Does this happen with OS X only?

Dunno, I don't have Windows or a stable Linux to test it on.

Is the bug in OpenAL-Soft or in SFML?

Since it works with the default implementation of OpenAL shipped by Apple, I'm inclined to think it's an issue with OpenAL-Soft implementation -- but we already use the most recent one...

(If SFML has a bug, it has been there for a very long time, thus rather unlikely.)

Member

mantognini commented May 28, 2015

Does this happen with OS X only?

Dunno, I don't have Windows or a stable Linux to test it on.

Is the bug in OpenAL-Soft or in SFML?

Since it works with the default implementation of OpenAL shipped by Apple, I'm inclined to think it's an issue with OpenAL-Soft implementation -- but we already use the most recent one...

(If SFML has a bug, it has been there for a very long time, thus rather unlikely.)

@CelticMinstrel

This comment has been minimized.

Show comment
Hide comment
@CelticMinstrel

CelticMinstrel Sep 21, 2015

I'm not quite sure if this is the same issue, but it looks pretty similar.

The following minimal code:

#include <iostream>
#include <SFML/Audio.hpp>

sf::Sound my_sound;

int main() {
    std::cout << "SFML Version: " << SFML_VERSION_MAJOR << '.'
        << SFML_VERSION_MINOR << '.'
        << SFML_VERSION_PATCH << std::endl;
    return 0;
}

when compiled with clang++ test.cpp -framework SFML -framework sfml-audio, produces the following output and terminates with SIGABRT:

SFML Version: 2.3.0
AL lib: (EE) alc_cleanup: 1 device not closed
Assertion failed: (lockret == althrd_success), function LockLists,
    file /Users/ceylo/al/openal-soft-1.16.0/Alc/ALc.c, line 779.
Abort trap: 6

The stack trace I get from Apple's reporter is pretty similar to what @mantognini posted:

0   libsystem_kernel.dylib          0x00007fff89834ce2 __pthread_kill + 10
1   libsystem_c.dylib               0x00007fff911cd7d2 pthread_kill + 95
2   libsystem_c.dylib               0x00007fff911bea7a abort + 143
3   libsystem_c.dylib               0x00007fff911f15de __assert_rtn + 146
4   org.sfml-dev.OpenAL             0x0000000105ef0f7c GetContextRef + 284
5   org.sfml-dev.OpenAL             0x0000000105ee120c alSourceStopv + 28
6   org.sfml-dev.OpenAL             0x0000000105ee11e9 alSourceStop + 25
7   org.sfml-dev.sfml-audio         0x0000000105b5fa5c sf::Sound::~Sound() + 28
8   com.spidweb.boesceneditor       0x00000001054e4873 __cxx_global_array_dtor + 51
9   libsystem_c.dylib               0x00007fff911be7c8 __cxa_finalize + 274
10  libsystem_c.dylib               0x00007fff911be652 exit + 18
11  com.spidweb.boesceneditor       0x0000000104edf72b start + 59

(Mind you, the above stack trace is not from the minimal program, but from another program exhibiting the same crash on exit. I'm not sure how to get such a stack trace from a command-line program.)

I'm also getting a similar issue (crash on exit) with SFML audio on Windows, but the same test code (compiled with cl test.cpp sfml-audio.lib) does not produce any useful output, so I'm not sure if it's actually the same issue.

CelticMinstrel commented Sep 21, 2015

I'm not quite sure if this is the same issue, but it looks pretty similar.

The following minimal code:

#include <iostream>
#include <SFML/Audio.hpp>

sf::Sound my_sound;

int main() {
    std::cout << "SFML Version: " << SFML_VERSION_MAJOR << '.'
        << SFML_VERSION_MINOR << '.'
        << SFML_VERSION_PATCH << std::endl;
    return 0;
}

when compiled with clang++ test.cpp -framework SFML -framework sfml-audio, produces the following output and terminates with SIGABRT:

SFML Version: 2.3.0
AL lib: (EE) alc_cleanup: 1 device not closed
Assertion failed: (lockret == althrd_success), function LockLists,
    file /Users/ceylo/al/openal-soft-1.16.0/Alc/ALc.c, line 779.
Abort trap: 6

The stack trace I get from Apple's reporter is pretty similar to what @mantognini posted:

0   libsystem_kernel.dylib          0x00007fff89834ce2 __pthread_kill + 10
1   libsystem_c.dylib               0x00007fff911cd7d2 pthread_kill + 95
2   libsystem_c.dylib               0x00007fff911bea7a abort + 143
3   libsystem_c.dylib               0x00007fff911f15de __assert_rtn + 146
4   org.sfml-dev.OpenAL             0x0000000105ef0f7c GetContextRef + 284
5   org.sfml-dev.OpenAL             0x0000000105ee120c alSourceStopv + 28
6   org.sfml-dev.OpenAL             0x0000000105ee11e9 alSourceStop + 25
7   org.sfml-dev.sfml-audio         0x0000000105b5fa5c sf::Sound::~Sound() + 28
8   com.spidweb.boesceneditor       0x00000001054e4873 __cxx_global_array_dtor + 51
9   libsystem_c.dylib               0x00007fff911be7c8 __cxa_finalize + 274
10  libsystem_c.dylib               0x00007fff911be652 exit + 18
11  com.spidweb.boesceneditor       0x0000000104edf72b start + 59

(Mind you, the above stack trace is not from the minimal program, but from another program exhibiting the same crash on exit. I'm not sure how to get such a stack trace from a command-line program.)

I'm also getting a similar issue (crash on exit) with SFML audio on Windows, but the same test code (compiled with cl test.cpp sfml-audio.lib) does not produce any useful output, so I'm not sure if it's actually the same issue.

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Sep 21, 2015

Member

I doubt it's the same issue. Your issue is most likely related to having a global sf::Sound object. Don't use global SFML resources. 😉

Member

eXpl0it3r commented Sep 21, 2015

I doubt it's the same issue. Your issue is most likely related to having a global sf::Sound object. Don't use global SFML resources. 😉

@CelticMinstrel

This comment has been minimized.

Show comment
Hide comment
@CelticMinstrel

CelticMinstrel Sep 21, 2015

Huh, you seem to be right. I guess I'll open a new issue, then.

CelticMinstrel commented Sep 21, 2015

Huh, you seem to be right. I guess I'll open a new issue, then.

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Sep 21, 2015

Member

Please don't open an issue for using global SFML resources.

Member

eXpl0it3r commented Sep 21, 2015

Please don't open an issue for using global SFML resources.

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini Feb 7, 2016

Member

Superseded by #1057.

Member

mantognini commented Feb 7, 2016

Superseded by #1057.

@mantognini mantognini closed this Feb 7, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment