Wrong cast() call causes access violation at vtable access

[saschanaz]

From this function where JXLWICBitmapFrameDecode implements IWICBitmapFrameDecode:

let frame_decode = JXLWICBitmapFrameDecode::new(frame.data.clone(), basic_info);
let casted: IWICBitmapFrameDecode = frame_decode.cast()?;

let mut width = 0u32;
let mut height = 0u32;
casted.GetSize(&mut width, &mut height)?;

The call to GetSize() throws without calling the actual implemented function:

Exception has occurred: W32/0xC0000005
Unhandled exception at 0x0000000000000000 in rundll32.exe: 0xC0000005: Access violation executing location 0x0000000000000000.

Not sure what's wrong here, maybe the metadata, ᅟor the use of cast(), or 🤷

The full code is here: https://github.com/saschanaz/jxl-winthumb/blob/caca0636f3802b8c7c26a6d37c6fb6976f868dbe/src/wic.rs#L119

[saschanaz]

Okay, it should be into() instead of cast() when casting from Rust type into Windows API type. But shouldn't cast() return Err in that case?

[kennykerr]

There should be some kind of assert that you've already boxed the object (via into) but right now cast assumes that's already happened.

[rylev]

The way that this is handled in com-rs is by doing the following:

• not exposing a new function which simply stack allocates (and relying that the user does the right thing and heap allocates)
• providing a type called ClassAllocation which is a wrapper around ManuallyDrop<Pin<Box<T>>>
  • this type ensures the invariant that the implementation is heap allocated, will not move, and is dropped by some external force (i.e., when the ref count is 0)
• The user is only ever exposed an allocate function which does the dance of putting the type on the heap and pinning it.

This works quite well and ensures that the user can never stack allocate the implementation type. Would something like this work for windows-rs as well?

[kennykerr]

I don't think that would work without some modification because the windows crate's implement macro is a proc_macro_attribute rather than the proc_macro in the com crate where you basically rewrite the entire implementation.