Debian Bookworm Segfault

[jspizziri]

Debian bookworm was released on 2023-06-10 and it seems as though the shaka-streamer-binaries aren't compatible with it. Things still work fine on bullseye, but just wanted to flag the issue for the future.

Specifically I'm seeing a segfault when calling ffprobe

[joeyparrish]

Thanks! Can you check a few things for me on Bookworm?

1. What is the output of ldd on the ffprobe binary we ship?
2. What is the output of file on that binary?
3. What is the output of file on a binary that ships with Debian Bookworm?

I hope that these things will help me understand the problem.

[jspizziri]

@joeyparrish I've not ventured into this type of territory before, so I might've done something wrong. But here's what I got:

ldd ffprobe

$ ldd /usr/local/lib/python3.11/site-packages/streamer_binaries/ffprobe-linux-x64
    not a dynamic executable

file ffprobe

$ file /usr/local/lib/python3.11/site-packages/streamer_binaries/ffprobe-linux-x64
/usr/local/lib/python3.11/site-packages/streamer_binaries/ffprobe-linux-x64: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=18be219ee289be6bfdf0293eca0050b9407e4f66, for GNU/Linux 3.2.0, stripped

file $(which file)

$ file $(which file)
/usr/bin/file: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=966425c361b63d074fc66bf6e1c2bb9abe6f3bd5, for GNU/Linux 3.2.0, stripped

My Environment

In case it helps I'm including the basic docker environment I ran all this with:

# Dockerfile
FROM python:3.11-slim-bookworm as dev

RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app

# hardware video acceleration
RUN apt update && apt install -y va-driver-all

COPY app/requirements.txt .
RUN --mount=type=cache,target=/root/.cache/pip \
    pip3 install -r requirements.txt

...

# app/requirements.txt
...
shaka-streamer
shaka-streamer-binaries
...

[jspizziri]

Whoops, accidental closure.

[joeyparrish]

I don't see any obvious reason why ffprobe should fail. It's statically linked as it should be, and it's the correct architecture, which matches the architecture of Debian's own executables... except for one detail, which I'm not familiar with. The Debian executable is marked pie, which I believe stands for "position independent executable", but that's roughly everything I know on the subject.

This is helpful info, though, and the Dockerfile is also very helpful. I should be able to look at it more closely in Docker, but I don't have much free time at the moment. If you want to continue looking into it yourself, you might want to check out the project where ffprobe gets built: https://github.com/shaka-project/static-ffmpeg-binaries

Specifically, what I would do to debug this is to manually run the build steps in this workflow: https://github.com/shaka-project/static-ffmpeg-binaries/blob/main/.github/workflows/build.yaml

I would run them on a Debian or Ubuntu host system other than Bookworm, possibly with a modification to the ffmpeg configure to enable debugging, then I would try them again on Bookworm. I would play with those two ffprobe executables, and I would use gdb to get a backtrace for the crash.

If the Bookworm-built executable works, that tells us that static linking is feasible in general, but maybe a special build is needed for Bookworm or similar systems. If any executable crashes in gdb with some meaningful backtrace, it may point to a specific feature or library that doesn't work in a static executable on Bookworm, which may point toward a resolution.

I don't have time to pursue this yet, so I hope this is useful information. I will try to get to this eventually, but I can't promise when. I'm very busy with the projects that are more critical to my employer.