uniffi-rs icon indicating copy to clipboard operation
uniffi-rs copied to clipboard

JVM segfault due to stack overflow

Open gtrak opened this issue 5 months ago • 2 comments
trafficstars

Edit: This was caused by a stackoverflow.

Original message:

I was surprised by this one, but I don't know where to start. Using uniffi 0.29.1.

My downstream code throws a Result like this, and it bubbles through the rust, gets passed around as an anyhow error, and eventually converted to a custom FFI struct:

#[derive(Debug, Error)]
pub enum Error {
...
    #[error("Unexpected response: {}", self)]
    UnexpectedResponseBody { status: i32, body: String },
}

It appears the offensive part is the self in #[error(..., self)], if I just encode status and body separately, it works fine.

// Java eventually hits some exported object methods to pick apart this custom struct,
// but not sure if it got that far
#[derive(Debug, uniffi::Object, thiserror::Error)]
#[uniffi::export(Debug, Display)]
pub struct FFIError {
    status: i32,
    error_code: Option<String>,
    message: String,
    details: Option<String>,
}

impl From<anyhow::Error> for FFIError {
    fn from(source: anyhow::Error) -> Self {
        // debug logs at least get this far
        Self {
            status: 500,
            error_code: None,
            // source is the original error enum wrapped in anyhow::Error
            message: source.to_string(),
            details: None,
        }
    }
}

This works fine:

#[derive(Debug, Error)]
pub enum Error {
...
    #[error("Unexpected response: {} {}", status, body)]
    UnexpectedResponseBody { status: i32, body: String },
}

It's worrisome that I'm not sure exactly how to avoid this kind of problem or where it could have gone wrong.

gtrak avatar Jun 14 '25 00:06 gtrak