Error in (also roundtrip) conversion on p21 soroban env

[errant rampart]

I've noticed that since we updated the zephyr vm to the main branch soroban environment, some conversions aren't working as expected.

As an example,

let val: Val = (
        Address::from_string(&zephyr_sdk::soroban_sdk::String::from_str(
            &env.soroban(),
            "GAWL2CH2JH5APO5GJZ5OH6SILW4XUFW7Z72FZDAAUOLK5QZTS363QDDC",
        )),
        863904_i128,
    )
        .try_into_val(env.soroban())
        .unwrap();

    let converted_back = <(Address, i128)>::try_from_val(env.soroban(), &val);

env.log()
        .debug(format!("Rountrip result {:?}", converted_back), None);

which is a circular conversion successfully converts the tuple to both val, but fails to be converted back to the tuple:

ZephyrLog { level: Debug, message: "Rountrip result Err(Error(Value, UnexpectedType))", data: None }

I remember this working before updating the zvm's soroban host to p21. My fork's tuple conversions are the same as the main branch's and have been around for two months already https://github.com/heytdep/rs-soroban-env/blob/main/soroban-env-common/src/tuple.rs.

What am I doing wrong here? How can I better debug this?

[errant rampart]

Also want to highlight that this only affects nested objects. For instance:

let val: Result<Val, zephyr_sdk::soroban_sdk::Error> =
        (86390000000000004_i128, 863904_i128).try_into_val(env.soroban());

    let converted_back = <(i128, i128)>::try_from_val(env.soroban(), &val.unwrap());

doesn't work, while

let val: Result<Val, zephyr_sdk::soroban_sdk::Error> =
        (8639000000000004_i128, 863904_i128).try_into_val(env.soroban());

    let converted_back = <(i128, i128)>::try_from_val(env.soroban(), &val.unwrap());

does (within 56 bytes)

[errant rampart]

oops it would seem that the issue might have to do with our new memory management layout, so might not be soroban related at all

investigating further

Ah yeah has to do with the way we (don't) handle relative/absolute objects. Sorry for opening this.

fwiw this still had to do with the p21 update and some changes in linmem unpacking, but the issue itself lied in zvm logic

[keen torrent]

cc @chrome olive @craggy tulip @paper widget this may warrant some 👀 from us? Even if the issue ended up being within the zyphervm, the fact there was observable difference between p21 and p22 that I haven't heard us discuss sounds like a surprise.

[errant rampart]

it may be worth looking into the actual change when I synced the branches. I'm assuming it's some new change to do with the soroban host because I don't recall changing things on that and noticed the object conversions were failing after some main branch merges (while they weren't failing before). I'll try to find the actual change and report back

looking into this, it does seem like there has been no changes at all in the svm vec memory unpack host fn, which makes me believe it might be a more subtle diff that caused this. Will try to reproduce tomorrow with the two different zvm versions

[keen torrent]

@errant rampart could you share the commit SHAs for the two versions of the soroban-env-host you were using, the before when it was fine, and then the commit you changed to where the difference arose?