x42/ltc-tools

SIGSEGV on Debian

Closed this issue · 4 comments

I get a segfault trying to run ltcdump 0.7.0 on a Debian machine. I'm using the binary from https://github.com/x42/ltc-tools/releases/download/v0.7.0/ltcdump-linux-x86_64-v0.7.0.zip . Interestingly, the i386 binary from the same release works fine on this machine.

uname -a: Linux deb-xps 5.10.0-4-amd64 #1 SMP Debian 5.10.19-1 (2021-03-02) x86_64 GNU/Linux

A sample input file on which the x86 version chokes: ZOOM0004_Tr1.WAV.gz (gzipped because GH prohibits .WAV attachments)

x42 commented

Works fine here (with local build of ltcdump).

What Zoom device was this file made with? More likely the issue is due to
libsndfile/libsndfile#370 or libsndfile/libsndfile#374

Thank you for your quick response, @x42.

The recording device is an H6. The file's metadata is accurate[1]. This file is from my test suite for LTCSync. It used to work fine on my previous laptop (Ubuntu) but is failing on my current machine (debian). I'm using pre-built, static binaries from https://github.com/x42/ltc-tools/releases/tag/v0.7.0, so it isn't obvious to me how the change in OS distribution would make a difference. I also find it fascinating that the x86_64 binary segfaults, but the i386 binary processes the file. If I build locally from the tip of ltc-tools master, the binary runs without issues.

Other WAV files from the LTCSync suite exhibit the same behavior, including ones generated in software and so free of ZOOM artifacts. I'm attaching an example: LTC_00_58_00_00__1mins_24.wav.gz (again, gzipped because GH refuses to attach .wav)

[1]

$ ffprobe -hide_banner ltcsync/samples/ZOOM0004_Tr1.WAV
 Input #0, wav, from 'ltcsync/samples/ZOOM0004_Tr1.WAV':
  Metadata:
    encoded_by      : ZOOM Handy Recorder H6
    date            : 2018-12-11
    creation_time   : 13:34:21
    time_reference  : 2345328000
    coding_history  : A=PCM,F=48000,W=16,M=mono,T=ZOOM Handy Recorder H6                       
  Duration: 00:00:13.20, bitrate: 787 kb/s
    Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, 1 channels, s16, 768 kb/s
x42 commented

The static builds use an ancient version of libsndfile with various known issues that are also arch dependent.

If I build locally from the tip of ltc-tools master, the binary runs without issues.

great. Thanks for checking. So this issue can be closed?

I suppose so. If you could make another release of static binaries with the latest and greatest, I would appreciate that. It would essentially be a copy of #13