Prodfiler

Failure to parse debug_frame stack deltas: CIE version 4 not supported

Hi! I’m test-driving prodfiler on my own Rust codebase, that powers my personal website.

The agent reports traces from dockerd, the prodfiler agent itself, etc. but nothing from my app (named “futile”).

The agent logs are full of:

time="2021-09-01T12:13:45.494755761Z" level=error msg="Failed to preload /proc/2556566/map_files/5647471cb000-564747c0d000 (/home/amos/futile/target/release/futile): failed to extract interval data: failed to extract stack deltas from /proc/2556566/map_files/5647471cb000-564747c0d000: failure to parse debug_frame stack deltas: failed to parse FDE 0x18: CIE 0x0 failed: CIE version 4 not supproted"

I’m assuming that’s the cause! I’m not sure what FDE / CIE stand for, nor why my executable has “CIE version 4”, but I’m opening this in case you do, and to be pinged when there’s another build of prodfiler I can try again, against my Rust application.

Hey,

would you be able to provide an example binary with that, as well as some information about how it was built? (Toolchain details etc.)?

This should be fixable on our end, we simply hadn’t encountered CIEv4 :slight_smile:

Cheers,
Thomas

Hey Thomas,

I’d be happy to send y’all a binary privately — it’s proprietary code, but I fully own it.

The app is built on Arch Linux, with rustc 1.53.0. It’s a release build, and it uses incremental compilation.

It is linked with “lld” (LLVM’s linker) rather than “GNU ld” thanks to this .cargo/config.toml file:

[target.x86_64-unknown-linux-gnu]
rustflags = [
    "-C", "link-arg=-fuse-ld=lld",
]

It has no notable dynamic dependencies:

$ ldd target/release/futile
        linux-vdso.so.1 (0x00007fff443dc000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f9ba3f5a000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f9ba3f39000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007f9ba3df4000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f9ba3ded000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f9ba3c20000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f9ba53a8000)

Here’s the Cargo manifest for it.

Let me know where I can send the binary for further examination! It’s very probable that it’s easy to get a repro case with a much smaller binary - if I was trying to reproduce that issue, I’d probably send prodfiler after something like sfz and see if that works.

I doubt the distro/kernel make a lot of difference here since Rust ships its own LLVM as far as I’m aware. Linking with “lld” might?? I don’t have enough knowledge of debuginfo to weigh in here.

Hey,

Thanks for the info! You can send the binary to support@optimyze.cloud.

Cheers,
Sean

Update: We have a fix for this deployed in our staging/testing infrastructure, and hope to cut a release with that fix during the next week.