Skip to content

fix(alsa): timespec segfault with 64-bit time_t on 32-bit systems - #1285

Open
roderickvd wants to merge 2 commits into
masterfrom
fix/alsa-timespec
Open

fix(alsa): timespec segfault with 64-bit time_t on 32-bit systems#1285
roderickvd wants to merge 2 commits into
masterfrom
fix/alsa-timespec

Conversation

@roderickvd

Copy link
Copy Markdown
Member

This stacks with diwic/alsa-rs#158.

@d3d9

@roderickvd

Copy link
Copy Markdown
Member Author

It fails to compile because you need to patch alsa-rs first.

@roderickvd

Copy link
Copy Markdown
Member Author

Despite the ongoing discussion over at diwic/alsa-rs#158, this patch seems correct, so I plan on merging it unless someone feels differently.

b0bbywan added a commit to b0bbywan/alsa-sys that referenced this pull request Jul 26, 2026
__TIMESIZE reports the port's default time_t width, so it still reads
32 on targets that gained a 64-bit time_t through Debian's time64
transition (_TIME_BITS=64 in the toolchain, e.g. armhf on trixie).
On those targets the probe from diwic#19 does not emit alsa_sys_time64,
libc::timespec stays 8 bytes, and libasound writes 16-byte timespecs
past it (diwic/alsa-rs#158, RustAudio/cpal#1285).

Measure the size directly instead: try to compile a _Static_assert
that sizeof(struct timespec) == 16. The snippet is compiled but never
run, so cross compiling against the target's sysroot keeps working.
A control compile first checks that <time.h> yields a usable timespec,
so a broken toolchain produces a warning and the safe 32-bit fallback
instead of being misread as a pre-transition target.

Verified on Raspberry Pi OS armhf: with this change the cfg is emitted
on trixie (16-byte timespec) and still not on bookworm (8-byte
timespec). 64-bit glibc and musl targets return early as before.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
diwic pushed a commit to diwic/alsa-sys that referenced this pull request Jul 29, 2026
* fix: measure sizeof(struct timespec) instead of reading __TIMESIZE

__TIMESIZE reports the port's default time_t width, so it still reads
32 on targets that gained a 64-bit time_t through Debian's time64
transition (_TIME_BITS=64 in the toolchain, e.g. armhf on trixie).
On those targets the probe from #19 does not emit alsa_sys_time64,
libc::timespec stays 8 bytes, and libasound writes 16-byte timespecs
past it (diwic/alsa-rs#158, RustAudio/cpal#1285).

Measure the size directly instead: try to compile a _Static_assert
that sizeof(struct timespec) == 16. The snippet is compiled but never
run, so cross compiling against the target's sysroot keeps working.
A control compile first checks that <time.h> yields a usable timespec,
so a broken toolchain produces a warning and the safe 32-bit fallback
instead of being misread as a pre-transition target.

Verified on Raspberry Pi OS armhf: with this change the cfg is emitted
on trixie (16-byte timespec) and still not on bookworm (8-byte
timespec). 64-bit glibc and musl targets return early as before.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix: probe snd_htimestamp_t via the ALSA headers and fail on probe errors

Review feedback from #20:

- Measure sizeof(snd_htimestamp_t) from <alsa/asoundlib.h> instead of
  struct timespec from <time.h>: it is the exact type libasound writes
  through. The probe now runs after pkg-config so it can reuse the
  reported include paths. The alsa/ prefix is required since alsa-lib
  1.2.5, when alsa.pc stopped adding -I${includedir}/alsa.

- If the control snippet does not compile, fail the build with an
  explicit error instead of assuming a 32-bit time_t: guessing 8 can
  segfault and guessing 16 yields garbage timestamps, so there is no
  safe fallback to pick silently.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant