Assertion fails in Rusty_V8 when trying to use `js_sandbox`

When i was trying to execute JS code in Rust, I came across this error:

thread 'main' panicked at /workspace/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rusty_v8-0.22.3/src/support.rs:556:5:
assertion `left == right` failed
  left: 16
 right: 8
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I have traced the failure to this bit of code in the library:

 fn write_u64(&mut self, value: u64) {
    // `TypeId` values are actually 64-bit values which themselves come out of
    // some hash function, so it's unnecessary to shuffle their bits further.
    assert_eq!(size_of::<TypeId>(), size_of::<u64>());
    assert_eq!(align_of::<TypeId>(), size_of::<u64>());
    let prev_state = self.state.replace(value);
    assert_eq!(prev_state, None);
  }

I looked at the TypeId struct, and it just seems to be a wrapper around u128. The project is located here so that you can look at it. The bot of code that is causing the issue (it compiles if the js_sandbox code is commented out):

for t in 0..DURATION {
        let mut t = t as f32;
        // let mut rng = thread_rng();

        let js_code = "function triple(t) { return t<2?(a=0,b=0,c=0):(a=.999*a+.001*random(),b<0?(b=.7*random(),c=random()):b-=1/44100,abs(256*a*(5*sin(t/5E4)+10)%256-128)+255*(t/300*(10*c+200)&2)*b**(random()/5+4))";
        let mut script = Script::from_string(js_code)?;
        t = script.call("triple", &t)?;


        wav.write_sample(t as SampleType)?;
    }

What is wrong here? Is this a bug on my end? How can I fix it?

The code you quote is making an unjustified assumption about the implementation details of a standard library type, which was true and is now false. This sort of code is incorrect and should be expected to break in this kind of way, if not even worse ones (run-time misbehavior instead of compile-time failure). What you should do about this situation is conclude that it's unwise to use rusty_v8.

According to their crates.io page the crate is obsolete and replaced by v8 anyway. v8 doesn't seem to contain the problematic code any more, but I have no idea if they have stopped relying on implementation details in general.

2 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.