samply 0.13.1 panics with "slice index starts at 8 but ends at 0"

[SauersML]

Hello, I'm encountering a panic in samply version 0.13.1 when trying to profile an application. The profiler crashes shortly after the target application begins execution, with the error "slice index starts at 8 but ends at 0" originating in samply::linux::perf_event::EventRef::get.

System Details:

• samply version: 0.13.1
• Operating System: Fedora Linux, aarch64 GNU/Linux
• Rust/Cargo version: rustc 1.88.0-nightly (d4f880f8c 2025-04-08), cargo 1.88.0-nightly (0e93c5bf6 2025-04-05)
• perf_event_paranoid: 1
• perf version: perf version 6.14.4-400.asahi.fc41.aarch64

I used samply record and got the error. The target application's logs are interleaved with the panic message, so the target starts correctly.

Panic Message & Backtrace:

thread '<unnamed>' panicked at /home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/samply-0.13.1/src/linux/perf_event.rs:34:72:
slice index starts at 8 but ends at 0
stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::slice::index::slice_index_order_fail::do_panic::runtime
   3: core::slice::index::slice_index_order_fail
   4: samply::linux::perf_event::EventRef::get
   5: <alloc::vec::Vec<T,A> as alloc::vec::spec_extend::SpecExtend<T,I>>::spec_extend
   6: samply::linux::profiler::run_profiler
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Full backtrace:

thread '<unnamed>' panicked at /home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/samply-0.13.1/src/linux/perf_event.rs:34:72:
slice index starts at 8 but ends at 0
stack backtrace:
   0:     0xaaab1adfce98 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h30ecff32d7faa824                                                 1:     0xaaab1ae23b60 - core::fmt::write::h887b96a1caad3405                                                             2:     0xaaab1adf8f24 - std::io::Write::write_fmt::hc0ab962aa377bc55                                                    3:     0xaaab1adfcd4c - std::sys::backtrace::BacktraceLock::print::hc93430a27340a611                                    4:     0xaaab1adfe8cc - std::panicking::default_hook::{{closure}}::he4a955b3cd05316e
   5:     0xaaab1adfe724 - std::panicking::default_hook::hcaea90408687a051                                                 6:     0xaaab1adff268 - std::panicking::rust_panic_with_hook::h5ca7b949ac1c4cac                                         7:     0xaaab1adfeff8 - std::panicking::begin_panic_handler::{{closure}}::h38b0d5988d5f3712                             8:     0xaaab1adfd3a0 - std::sys::backtrace::__rust_end_short_backtrace::h9ba4958fa0e54e0b                              9:     0xaaab1adfeca8 - __rustc[8a6480b3f5e8ef7f]::rust_begin_unwind                                                   10:     0xaaab1a5f2a44 - core::panicking::panic_fmt::hf23b48a563a1e6b8                                                  11:     0xaaab1a5f2fe4 - core::slice::index::slice_index_order_fail::do_panic::runtime::h004e0906738e92fa               12:     0xaaab1a5f2dcc - core::slice::index::slice_index_order_fail::h66cd76c16f93225e
  13:     0xaaab1a6f13fc - samply::linux::perf_event::EventRef::get::h9fa79f27a72197af
  14:     0xaaab1a7a9b7c - <alloc::vec::Vec<T,A> as alloc::vec::spec_extend::SpecExtend<T,I>>::spec_extend::h7ac2d72f11c8107b
  15:     0xaaab1a720df0 - samply::linux::profiler::run_profiler::h454a2dacc7f11102
  16:     0xaaab1a70a03c - std::sys::backtrace::__rust_begin_short_backtrace::h85f83d80a57ac5f8
  17:     0xaaab1a628a00 - core::ops::function::FnOnce::call_once{{vtable.shim}}::he950b71d171e8c3d
  18:     0xaaab1ae01280 - std::sys::pal::unix::thread::Thread::new::thread_start::h1db50478ba418060
  19:     0xfffed151bd68 - start_thread
  20:     0xfffed158794c - thread_start
  21:                0x0 - <unknown>

The panic occurs on line 34 of src/linux/perf_event.rs within the SliceLocation::get method:

SliceLocation::Single(ref range) => RawData::Single(&buffer[range.clone()]),

The error message "slice index starts at 8 but ends at 0" means that the range variable in this line evaluates to an invalid range, specifically 8..0.

This range is constructed as event_data_position..next_event_position when SliceLocation::Single is created within the next_raw_event function.

Looking at the calculation of these variables in next_raw_event:

• event_data_position is calculated as (relative_position + mem::size_of::<PerfEventHeader>() as u64) as usize. The size of PerfEventHeader is 8 bytes.
• next_event_position is calculated as event_position + event_header.size as usize.
• event_position is relative_position as usize.

If relative_position (and thus event_position) is 0, and the event_header.size (read from the perf event ring buffer) is also 0:

1. event_data_position would be (0 + 8) as usize = 8.
2. next_event_position would be 0 + 0 as usize = 0.

This results in the SliceLocation::Single variant being created with the range 8..0. Subsequently, when SliceLocation::get is called, the attempt to slice the buffer as &buffer[8..0] triggers the panic. Perhaps this is from an event_header.size of 0 leading to an invalid slice definition.

samply successfully sets up the performance monitoring:

• perf_event_open calls succeed for each CPU, returning valid file descriptors (e.g., 8 through 15 in one run).
• Then mmap calls on these file descriptors to create the ring buffers also succeed.
• No ioctl calls for enabling events were observed immediately after.

Using perf by itself also works, so perhaps the error occurs during samply's processing of event data read from these mmap'd memory regions.

Related issue which I am able to replicate: #467

samply record rustup check also fails with "slice index starts at 8 but ends at 0."