Segfault on alpine linux in alsa::pcm::PCM::open

[lxea]

alsa::pcm::PCM::open (pcm.rs:135) due to (as far as i can tell) the variable 'r' being 0x0

I'm not sure how to proceed, the program i've been using to narrow it down was this from the synth-example

fn main() {
    let args: Vec<_> = std::env::args().collect();
    let req_devname = format!("hw:{}", args[1]);
    let p = alsa::PCM::new(&req_devname, alsa::Direction::Playback, false);
 }

Might it be an issue from alpine using musl?

[diwic]

alsa::pcm::PCM::open (pcm.rs:135) due to (as far as i can tell) the variable 'r' being 0x0

The variable is set to null and the call to snd_pcm_open fills it in.

I'm not sure how to proceed,

I would run the program with a debugger (such as gdb) and when the program segfaults, get a full backtrace. Are you familiar with gdb?

[lxea]

I'm not super familiar with gdb but i ran it, and got the got bt -full:

(gdb) bt -full
#0  0x0000000000000000 in ?? ()
No symbol table info available.
#1  0x00007ffff7f92a92 in alsa::pcm::PCM::open (name=0x7ffff7fff140, dir=alsa::Direction::Playback, nonblock=false) at /home/alex/alsa-rs/src/pcm.rs:135
        flags = 0
        stream = 0
        r = 0x0
#2  0x00007ffff7f92861 in alsa::pcm::PCM::new (name=..., dir=alsa::Direction::Playback, nonblock=false) at /home/alex/alsa-rs/src/pcm.rs:120
No locals.
#3  0x00007ffff7f92161 in synth_example::main () at src/main.rs:320
        req_devname = alloc::string::String {vec: alloc::vec::Vec<u8> {buf: alloc::raw_vec::RawVec<u8, alloc::alloc::Global> {ptr: core::ptr::unique::Unique<u8> {pointer: 0x7ffff7fff120, _marker: core::marker::PhantomData<u8>}, cap: 12, alloc: alloc::alloc::Global}, len: 8}}
        args = alloc::vec::Vec<alloc::string::String> {buf: alloc::raw_vec::RawVec<alloc::string::String, alloc::alloc::Global> {ptr: core::ptr::unique::Unique<alloc::string::String> {pointer: 0x7ffff7fff220, _marker: core::marker::PhantomData<alloc::string::String>}, cap: 2, alloc: alloc::alloc::Global}, len: 2}

[diwic]

Okay, so it looks like the problem is the C library binding itself somehow? I e, the Rust code is supposed to call a C library function, snd_pcm_open but instead it ends up at 0x0 because the function pointer to snd_pcm_open is not initialized.

I don't think alsa-rs/alsa-sys is doing anything strange in this matter, so it's probably an "alpine linux" + Rust + C-bindings issue but it's hard to know for sure.

[diwic]

Side note: Have you modified alsa-rs in any way, or running an old version, or something?
Because PCM::open ends at line 131 and your backtrace says pcm.rs:135.

[lxea]

Because PCM::open ends at line 131 and your backtrace says pcm.rs:135.

I'm at the git latest, I'd added some prints before, I just forgot about them but the bt is the same when i remove them.

[diwic]

So, what about the build process? Do you cross-compile or not? Have you successfully dynamically bound to other C libraries in the same build environment? (Static linking is not supported, PRs welcome.)
Tried building in a Docker container? ( https://github.com/emk/rust-musl-builder )

[lxea]

I gave a try to building with the container you mentioned, I mounted the PWD etc as the readme says and then entered the container with sh so i could install the alsa headers when try to build it in the container, once it built, i wasnt able to run it within the container as it had some sort of linking issue resulting in $executable: not found which was a little weird, but it ran (and segfaulted unfortunately) outside the container, however i did have to ln libc which was also a bit weird, but it gave me a bigger backtrace:

(gdb) bt -full
#0  0x00007ffff7ebee4d in ?? () from /usr/lib/libasound.so.2
No symbol table info available.
#1  0x00007ffff7ebb344 in ?? () from /usr/lib/libasound.so.2
No symbol table info available.
#2  0x00007ffff7ebb54e in ?? () from /usr/lib/libasound.so.2
No symbol table info available.
#3  0x00007ffff7ebb9f9 in snd_config_update_r () from /usr/lib/libasound.so.2
No symbol table info available.
#4  0x00007ffff7ebbba2 in snd_config_update_ref () from /usr/lib/libasound.so.2
No symbol table info available.
#5  0x00007ffff7ed384c in snd_pcm_open () from /usr/lib/libasound.so.2
No symbol table info available.
#6  0x0000000000408a4c in alsa::pcm::PCM::open (name=0x672140, dir=alsa::Direction::Playback, nonblock=false)
    at /home/rust/.cargo/registry/src/github.com-1ecc6299db9ec823/alsa-0.4.3/src/pcm.rs:131
        flags = 0
        stream = 0
        r = 0x0
#7  0x000000000040895f in alsa::pcm::PCM::new (name=..., dir=alsa::Direction::Playback, nonblock=false)
    at /home/rust/.cargo/registry/src/github.com-1ecc6299db9ec823/alsa-0.4.3/src/pcm.rs:120
No locals.
#8  0x0000000000407196 in synth_example::main () at src/main.rs:317
        req_devname = alloc::string::String {vec: alloc::vec::Vec<u8> {buf: alloc::raw_vec::RawVec<u8, alloc::alloc::Global> {ptr: core::ptr::unique::Unique<u8> {pointer: 0x672120, _marker: core::marker::PhantomData<u8>}, cap: 12, alloc: alloc::alloc::Global}, len: 8}}
        args = alloc::vec::Vec<alloc::string::String> {buf: alloc::raw_vec::RawVec<alloc::string::String, alloc::alloc::Global> {ptr: core::ptr::unique::Unique<alloc::string::String> {pointer: 0x672240, _marker: core::marker::PhantomData<alloc::string::String>}, cap: 2, alloc: alloc::alloc::Global}, len: 2}

[diwic]

Okay, so that's a different error as now you're actually able to call snd_pcm_open, which you weren't before. But anyhow this sounds less and less like something related to alsa-sys and more like something related to muslc/rust/toolchain/something.

Can I ask you to read up a little on this and perhaps seek support from the muslc/rust-people instead? Because I'm not really qualified to help you. I am interested in having alsa-sys working on as many platforms as possible though so if you come back with more information/PR/etc I'll be happy to talk/review/merge further.

[diwic]

I'm closing this due to inactivity, and because this is probably about the build process rather than alsa-sys. Feel free to reopen in case circumstances change or new information arises. Thanks!

[eladyn]

Just in case someone else stumbles upon this issue: In my case, this was due to a problem in this specific chain (rust, linking to shared system libraries, musl), which is described here. A workaround can be found in this comment.