alsa: segfault on 32-bit platforms with 64-bit time_t

[d3d9]

I was calling rodio's open_default_sink() and got a segfault within cpal, after a message on the discord channel I was asked to try the beep example and it keeps happening.

From the initial report:

• Pi Zero W (arm-unknown-linux-gnueabihf)
• snd_rpi_hifiberry_dac
• rodio v0.22.2 - cpal v0.17.3 - alsa v0.11.0 - alsa-sys v0.4.0
• alsa-info: https://alsa-project.org/db/?f=3412cb46d09b9bddf68336d299e78ee3a61f6ee0
• I've tried looping through the output_devices() of the Host and choosing a specific one based on a condition, but it didn't help

Program received signal SIGSEGV, Segmentation fault.
0x00457620 in cpal::host::alsa::Device::build_stream_inner (self=<error reading variable: Cannot access memory at address 0xffffff38>, 
    conf=<error reading variable: Cannot access memory at address 0xffffff3c>, sample_format=cpal::samples_formats::SampleFormat::I32,
    stream_type=<error reading variable: Cannot access memory at address 0xffffff41>) at src/host/alsa/mod.rs:383
383             let ts = handle.status()?.get_htstamp();

Beep example (cpal @ the latest 45000c1):

$ target/debug/examples/beep
Output device: alsa:default
Default output config: SupportedStreamConfig { channels: 2, sample_rate: 44100, buffer_size: Range { min: 64, max: 131072 }, sample_format: I32 }
Segmentation fault
$ rust-gdb target/debug/examples/beep
(...)
Reading symbols from target/debug/examples/beep...
(gdb) run
Starting program: /home/...../cpal/target/debug/examples/beep 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Output device: alsa:default
Default output config: SupportedStreamConfig { channels: 2, sample_rate: 44100, buffer_size: Range { min: 64, max: 131072 }, sample_format: I32 }

Program received signal SIGSEGV, Segmentation fault.
0x0044d820 in cpal::host::alsa::Device::build_stream_inner (
    self=<error reading variable: Cannot access memory at address 0xffffff04>, conf=...,
    sample_format=cpal::samples_formats::SampleFormat::I32,
    stream_type=<error reading variable: Cannot access memory at address 0xffffff09>)
    at src/host/alsa/mod.rs:408
408             let ts = handle.status()?.get_htstamp();

[roderickvd]

Thanks. This one is not immediately obvious. Could you help with the following:

1. A full GDB backtrace (bt full or thread apply all bt full)
2. Separately, test with cargo run --example beep -- --device "alsa:hw:CARD=sndrpihifiberry,DEV=0" to bypass the route plugin you set up
3. Again separately, test with cargo run --example beep --release to rule out debug-build frame size

[d3d9]

1. A full GDB backtrace (bt full or thread apply all bt full)

#0  0x0044d820 in cpal::host::alsa::Device::build_stream_inner (
    self=<error reading variable: Cannot access memory at address 0xffffff04>, conf=...,
    sample_format=cpal::samples_formats::SampleFormat::I32,
    stream_type=<error reading variable: Cannot access memory at address 0xffffff09>)
    at src/host/alsa/mod.rs:408
        num_descriptors = <error reading variable num_descriptors (Cannot access memory at address 0xffffff4c)>
        period_samples = <error reading variable period_samples (Cannot access memory at address 0xffffff48)>
        can_pause = <error reading variable can_pause (Cannot access memory at address 0xffffff37)>
        handle = alsa::pcm::PCM (0x5ce060, Cell = {value = false})
        open_result = core::result::Result<alsa::pcm::PCM, (alsa::error::Error, i32)>::Ok(alsa::pcm::PCM (0x5ce060, Cell = {value = false}))
Backtrace stopped: Cannot access memory at address 0x4

2. Separately, test with cargo run --example beep -- --device "alsa:hw:CARD=sndrpihifiberry,DEV=0" to bypass the route plugin you set up

Output device: alsa:hw:CARD=sndrpihifiberry,DEV=0
Default output config: SupportedStreamConfig { channels: 2, sample_rate: 44100, buffer_size: Range { min: 64, max: 131072 }, sample_format: I32 }
Segmentation fault

3. Again separately, test with cargo run --example beep --release to rule out debug-build frame size

Running `target/release/examples/beep`
Output device: alsa:default
Default output config: SupportedStreamConfig { channels: 2, sample_rate: 44100, buffer_size: Range { min: 64, max: 131072 }, sample_format: I32 }
Segmentation fault

[roderickvd]

What does ulimit -s say?

And if you run ulimit -s unlimited && cargo run —example beep?

[d3d9]

$ ulimit -s
8192
$ ulimit -s unlimited && cargo run --example beep
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.75s
     Running `target/debug/examples/beep`
Output device: alsa:default
Default output config: SupportedStreamConfig { channels: 2, sample_rate: 44100, buffer_size: Range { min: 64, max: 131072 }, sample_format: I32 }
Segmentation fault

[roderickvd]

I think this is the same as diwic/alsa-rs#150 which was fixed only in part. The issue may be that you have a 64-bit time_t on a 32-bit platform, writing 8 bytes past the stack frame and causing a segfault.

If you could verify this alsa-rs branch before I open a PR on that repository?
Right now I don't have a 32-bit system to test it on myself.

Please put this in your Cargo.toml:

[patch.crates-io]
alsa = { git = "https://github.com/roderickvd/alsa-rs", branch = "fix/htstamp-time64-overflow" }

Then run cargo update -p alsa to force Cargo to resolve the patched version and rebuild.

[d3d9]

With that it seems to work in release mode, though I'm not physically there anymore to confirm actual audio output.
Panics in debug mode:

$ RUST_BACKTRACE=1 cargo run --example beep
Output device: alsa:default
Default output config: SupportedStreamConfig { channels: 2, sample_rate: 44100, buffer_size: Range { min: 64, max: 131072 }, sample_format: I32 }

thread 'cpal_alsa_out' (7292) panicked at src/host/alsa/mod.rs:1173:17:
attempt to multiply with overflow
stack backtrace:
   0: __rustc::rust_begin_unwind
             at /rustc/01f6ddf7588f42ae2d7eb0a2f21d44e8e96674cf/library/std/src/panicking.rs:689:5  
   1: core::panicking::panic_fmt
             at /rustc/01f6ddf7588f42ae2d7eb0a2f21d44e8e96674cf/library/core/src/panicking.rs:80:14 
   2: core::panicking::panic_const::panic_const_mul_overflow
             at /rustc/01f6ddf7588f42ae2d7eb0a2f21d44e8e96674cf/library/core/src/panicking.rs:175:17
   3: cpal::host::alsa::timespec_to_nanos
             at ./src/host/alsa/mod.rs:1173:17
   4: cpal::host::alsa::timespec_diff_nanos
             at ./src/host/alsa/mod.rs:1184:5
   5: cpal::host::alsa::stream_timestamp_hardware
             at ./src/host/alsa/mod.rs:1144:17
   6: cpal::host::alsa::process_output
             at ./src/host/alsa/mod.rs:1088:13
   7: cpal::host::alsa::output_stream_worker
             at ./src/host/alsa/mod.rs:891:19
   8: cpal::host::alsa::Stream::new_output::{{closure}}
             at ./src/host/alsa/mod.rs:1246:17

[roderickvd]

Good - we isolated the problem. Please try again with my latest commits to both cpal and my patched alsa-rs branch. If all is well, it should work now 🤞