1. Forum
  2. Fidonet
  3. SYNC PROGRAMMING

  • src/xpdev/xpbeep.c

    From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Wed May 6 19:41:53 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/bb2f365233ea170ef1506d92
    Modified Files:
    src/xpdev/xpbeep.c
    Log Message:
    xpbeep: hold r->mutex when reading auto_close/done in reaper (CIDs 645736, 645739)

    xp_audio_open's stream-reaper loop read r->auto_close and r->done while
    holding only mixer_lock, but those flags are written elsewhere
    (xp_audio_stop, the auto_close setter) under r->mutex only — not
    mixer_lock. Coverity flagged the inconsistent locking; in practice it
    could let the reaper see stale flag values and either skip a reapable
    stream (benign — gets reaped on the next open) or, if a future writer
    ever clears done while close-pending, cause a missed reap.

    Take r->mutex briefly to read the flags, then release it before free_stream_locked() (which destroys the mutex). Lock order
    mixer_lock -> r->mutex matches xp_mixer_pull and xp_audio_close, so no
    deadlock risk introduced.

    This does NOT address the broader stream_from_handle()-returns-pointer
    lifetime issue; that's an architectural concern for a separate change.

    Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Windows 11)@1:103/705 to Git commit to main/sbbs/master on Wed May 6 21:20:12 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/be3ca40eb04a5c95a761ff7d
    Modified Files:
    src/xpdev/xpbeep.c
    Log Message:
    Fix Borland C++ build of xp_audio_open()

    Broken by Claude
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to Git commit to main/sbbs/master on Sun May 10 15:18:55 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/412828ad24fe4868c84fa62e
    Modified Files:
    src/xpdev/xpbeep.c
    Log Message:
    xpbeep: init mixer_lock from xp_mixer_pull too, not just xp_audio_open

    mixer_lock is initialized lazily via pthread_once(&mixer_once, ...) in xp_audio_open. The pull side (push-backend device threads, pull-
    backend callbacks like the WASAPI render thread) was relying on at
    least one xp_audio_open having run first to set the mutex up. That
    held for ANSI-music / APC patches because those paths always open at
    least one xp_audio stream before producing samples, but the OOII
    enable path just calls xptone_open() with no stream, and on Win32 the
    WASAPI render thread fired before the mixer once-init had ever run.
    First xp_mixer_pull call locked an uninitialized mutex and the SEH
    exception terminated the whole process.

    POSIX is more forgiving about zero-initialized pthread_mutex_t values
    so the same call path didn't crash there, but it was still
    technically uninitialized. Calling the once-init from xp_mixer_pull
    makes the mutex safe regardless of which side runs first.

    Fixes ticket 249.

    Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)