Reject types with a niche in copy_struct/copy_vec

[korniltsev-grafanista-yolo-vibecoder239]

ProcessMemory::copy_struct<T: Copy> materializes a T out of bytes read from
another process. T: Copy does not mean every bit pattern is a valid T, and
when T has a niche, rustc may put the discriminant of the returned
Result<T, Error> inside it — if the niche leaves no room for a real tag, it
will:

fn copy_struct<T: Copy>(&self, addr: usize) -> Result<T, Error> {
    let mut data = vec![0; std::mem::size_of::<T>()];
    self.read(addr, &mut data)?;
    Ok(unsafe { std::ptr::read(data.as_ptr() as *const _) })
}

A stale read whose bytes happen to hit the niche value then comes back as an
Err(Error) whose payload is 32 bytes of target memory. The caller usually
contexts it into an anyhow::Error; when that is dropped, drop_glue reads the
first word as an enum discriminant, selects a String-owning variant, and frees
the next word as a heap pointer.

The real case

This is the root cause of a free(): invalid pointer / SIGSEGV in py-spy on
Python 3.11, reported against the Pyroscope Python agent and root-caused in
grafana/pyroscope-python#146
(disassembly of the shipped wheel, four decoded core dumps, deterministic
reproducer). py-spy's 3.11 _PyInterpreterFrame binding declares is_entry as
a bool at offset 68, which is the struct's only niche. The 32-byte Error
fits in the bytes below it, so rustc niche-fills the Result into that byte
rather than adding a tag:

size_of::<v3_11_0::_PyInterpreterFrame>()               == 80
size_of::<Result<_PyInterpreterFrame, remoteprocess::Error>>() == 80

so the Err tag is stored in is_entry, and the shipped code really does
cmp $0x2, %al on that byte to decide whether the read failed.

The change

Assert at compile time that copied types have no niche, using the fact that a
niche-free type always makes Option<T> strictly larger than T. copy_pointer
is covered for free because it delegates to copy_struct; copy_vec gets the
same line since it builds its Vec<T> without going through copy_struct.

Not a breaking change: the bound stays T: Copy. Consumers that copy
niche-free types — integers, floats, raw pointers, Option<extern fn>, arrays
and #[repr(C)] structs of those — are unaffected. The ones that aren't were
already unsound.

I considered bytemuck::AnyBitPattern as the bound instead, and it does not work
here: bytemuck only implements Pod for *const T/*mut T behind its
unsound_ptr_pod_impl feature and never for C function pointers, so
#[derive(AnyBitPattern)] rejects essentially every FFI struct a consumer of
this crate would want to copy. It would also be a breaking API change.

Effect on py-spy

Building py-spy (master, 32080cc) against this branch fails with exactly two
rejections, both genuine:

error[E0080]: evaluation panicked: this type has a niche: not every bit pattern is a valid value, ...
    = note: evaluation of `remoteprocess::AssertNoNiche::<python_bindings::v3_11_0::_PyInterpreterFrame>::ASSERT` failed here
note: the above error was encountered while instantiating `fn <Process as ProcessMemory>::copy_struct::<v3_11_0::_PyInterpreterFrame>`

error[E0080]: evaluation panicked: this type has a niche: ...
    = note: evaluation of `remoteprocess::AssertNoNiche::<bool>::ASSERT` failed here
note: the above error was encountered while instantiating `fn <Process as ProcessMemory>::copy_struct::<bool>`

The first is the known crash. The second was previously unknown:
python_data_access.rs reads a numpy.bool_'s payload byte straight into a Rust
bool (format_obval::<bool, P>), i.e. an arbitrary target byte materialized as
a bool. With those two fixed (is_entry → c_char, numpy.bool → u8),
py-spy builds clean with default features, --no-default-features,
--features cli and --all-targets, and its unit tests pass — so the check
accepts every other type py-spy copies across all 14 CPython binding modules,
including the function-pointer-heavy PyTypeObject/PyHeapTypeObject.

Tests

cargo test passes unchanged.

🤖 Generated with Claude Code

[NaurisSadovskis]

@benfred hi, I reported initial issue in Grafana slack channel. Happy to provide more information if needed as it's fairly easy to reproduce it on our end.