openal-info crashes with no devices

[minghia]

When I try to run openal-info on a machine that appears to have no devices I get the following:
Available playback devices:
ALSA Default
Available capture devices:
ALSA Default
Default playback device: ALSA Default
Default capture device: ALSA Default
ALC version: 1.1

** Info for device "ALSA Default" **
ALC version: 1.1
ALC extensions:
ALC_ENUMERATE_ALL_EXT, ALC_ENUMERATION_EXT, ALC_EXT_CAPTURE,
ALC_EXT_DEDICATED, ALC_EXT_disconnect, ALC_EXT_EFX,
ALC_EXT_thread_local_context, ALC_SOFT_device_clock, ALC_SOFT_HRTF,
ALC_SOFT_loopback, ALC_SOFT_output_limiter, ALC_SOFT_pause_device
Available HRTFs:
Built-In 44100hz
Built-In 48000hz
Segmentation fault (core dumped)

Running it under gdb I get the following backtrace when the program seg faults:

Program received signal SIGSEGV, Segmentation fault.
0x0000003d23c924b0 in ?? () from /lib64/libasound.so.2
(gdb) up
#1 0x00007ffff7d6ae05 in ALCplaybackAlsa_reset ()
from openal-soft-1.19.1/build/libopenal.so.1
(gdb) up
#2 0x00007ffff7d6a009 in ALCplaybackAlsa_ALCbackend_reset ()
from openal-soft-1.19.1/build/libopenal.so.1
(gdb) up
#3 0x00007ffff7d2c450 in UpdateDeviceParams ()
from openal-soft-1.19.1/build/libopenal.so.1
(gdb) up
#4 0x00007ffff7d31b80 in alcCreateContext ()
from openal-soft-1.19.1/build/libopenal.so.1

I am running on Centos 6 using gcc 4.9.4. If I run on a machine with a sound card I get the expected output.

Maybe the code needs to indicate that there are no devices present similar to what aplay -l gives
aplay: device_list:223: no soundcards found...

[kcat]

Can you get a backtrace from a build with debug info? It looks like it's crashing in libasound, and unfortunately there's no line numbers to indicate which call OpenAL Soft is making to cause the crash.

Maybe the code needs to indicate that there are no devices present

That may be a bit more difficult than it seems. aplay -l enumerates the list of hardware devices on the system, whereas OpenAL Soft enumerates the default device and the hardware devices. However ALSA's default device is not necessarily linked to hardware (by default it actually backs on dmix or pulse, or it can be a network device, or a dummy/noop device), so the lack of hardware devices doesn't necessarily mean there's no ALSA Default to use. That's not known until it's attempted to be used (and by the looks of it the default device does open, it just crashes when attempting to configure its parameters).

[minghia]

I thought I built it with Debug as the default Cmake built type was RelWithDebInfo. I tried with Debug as well but I couldn't step through the code. I'll try again tomorrow. I'm guessing I was unlucky to try on a machine with no ALSA sound card configured. By the way is there any reason why there is a dependency on libatomic under Linux?

[kcat]

By the way is there any reason why there is a dependency on libatomic under Linux?

On some systems, libatomic is needed for certain atomic operations. Unfortunately there's no simple way to test whether a particular system target needs the lib for any of the numerous atomic operations that get called or may be called in the future, so if the lib exists it's linked in just in case.

[minghia]

It appears that openal 1.12 doesn't have the problem. I can't seem to get any debug symbols when I load 1.19.1. If I had to guess it is the cast on this line because it gets the segfault rather quickly as it single steps in the function:
ALCdevice *device = STATIC_CAST(ALCbackend, self)->mDevice;

[kcat]

That line's not a problem, it's just accessing a field in the self object. It's not crashing in OpenAL Soft's code, but in ALSA's:

Program received signal SIGSEGV, Segmentation fault.
0x0000003d23c924b0 in ?? () from /lib64/libasound.so.2
(gdb) up
#1 0x00007ffff7d6ae05 in ALCplaybackAlsa_reset ()
from openal-soft-1.19.1/build/libopenal.so.1

libopenal is making a call to libasound, and it crashes in libasound. And unfortunately, without line numbers/debug info, I can't tell what call libopenal is making that causes the crash.