Get corrupt self in service methods

[Chaoses-Ib]

I'm sorry for another question, but this one has really been bothering me for a long time.

My Rust interface is:

#[ffi_type(opaque)]
pub struct SearchResult<'a> {
    // ...
}

#[ffi_service(error = "FFIError", prefix = "search_result")]
impl<'a> SearchResult<'a> {
    #[ffi_service_method(on_panic = "return_default")]
    pub fn get_result_detail(
        &self,
        index: u64,
    ) -> SearchResultDetail {
        println!("get_result_detail {}", unsafe{ self as *const _ as u64 });
        do_some_thing_with(self);
    }
}

And the C# binding generated by C# backend:

[DllImport(NativeLib, CallingConvention = CallingConvention.Cdecl, EntryPoint = "search_resultget_result_detail")]
public static extern IntPtr search_resultget_result_detail(IntPtr context, ulong index);

public partial class SearchResult : IDisposable
{
    public IntPtr GetResultDetail(ulong index)
    {
        return Interop.search_resultget_result_detail(_context, index);
    }
}

SearchResult result = ...;
IntPtr detail = result.GetResultDetail(1);

This looks good, but when I run it, I get a memory access exception:

When I change index to 3, the address will change at the same time:

This means that the second argument index is used as self, which is very strange.

I have expanded the macro to see what was going on, but everything looks fine:

#[no_mangle]
#[allow(unused_mut, unsafe_op_in_unsafe_fn)]
#[allow(clippy::needless_lifetimes, clippy::extra_unused_lifetimes)]
pub extern "C" fn search_resultget_result_detail<'a>(
    context: &SearchResult<'a>,
    index: u64,
) -> SearchResultDetail {
    let result_result = ::std::panic::catch_unwind(
        std::panic::AssertUnwindSafe(|| {
            let context = context;
            let index = index;
            <SearchResult>::get_result_detail(context, index)
        }),
    );
    match result_result {
        Ok(x) => x,
        Err(e) => {
            ::interoptopus::util::log_error(|| {
                let res = ::alloc::fmt::format(
                    format_args!(
                        "Panic in ({0}): {1:?}",
                        "search_resultget_result_detail", e
                    ),
                );
                res
            });
            <SearchResultDetail>::default()
        }
    }
}

Do you have any idea?

[ralfbiedert]

Some things to check:

• Are you sure the binding matches the DLL? I've seen similar UB a few times, and usually it's people forgetting to rebuild the DLL, and / or load an old DLL.
• Related, it's highly recommended to use the API guard to actually make sure you load the right thing.
• Also, could you produce a minimal self-contained example and post the link?

[Chaoses-Ib]

I have added an API guard and got something like this:

static Interop()
{
    var api_version = Interop.my_api_guard();
    if (api_version != 6255757951497524891ul)
    {
        throw new TypeLoadException($"API reports hash {api_version} which differs from hash in bindings (6255757951497524891). You probably forgot to update / copy either the bindings or the library.");
    }
}

However, there is still the memory access exception. I'll try to make a reproducible demo.

[Chaoses-Ib]

Here is the demo: https://github.com/listary/interoptopus/tree/corrupt-self-demo

When you run it, you should be able to see the exception:

[ralfbiedert]

Oh, the problem is the SearchResultDetail not shown here. You declare that

#[derive(Default)]
#[ffi_type(opaque)]
pub struct SearchResultDetail {
    pub a: String,
    pub b: bool
}

and attempt to return it by value. There are two issues here:

• The type is marked opaque. These are only meant to be used with a pointer, never directly. You can see that on the C# side it declares an IntPtr for that, but now that would imply transmuting that struct to an IntPtr, which doesn't work. Interoptopus is probably a bit blame here, and we should error / panic when seeing opaques passed by value
• Also, even if you could pass these by value, you mustn't, as a is String, and there is simply nothing you can do in C# with that string. You can't even deallocate it, and even if you could return it back to Rust you'd probably run into UB.

[Chaoses-Ib]

OK, now I can make it work. I think it's a bit confusing that ffi_service_ctor can return a struct directly, but ffi_service_method has to return a pointer to the struct even if it's marked opaque. Anyway, thanks for your help.

[ralfbiedert]

I think it's a bit confusing that ffi_service_ctor can return a struct directly, but ffi_service_method has to return a pointer to the struct even if it's marked opaque.

Yes, I agree. Created an issue #84, we should emit an error.