Stream: git-wasmtime

Topic: wasmtime / issue #4342 Enabling epoch interruption withou...

view this post on Zulip Wasmtime GitHub notifications bot (Jun 28 2022 at 02:47):

JMS55 labeled issue #4342:

Test Case

https://github.com/JMS55/wasmtime-epoch-test

Steps to Reproduce

Expected Results

For it to print 17 both times. I expect that if I don't set an epoch deadline, then the code won't ever get interrupted.

Actual Results

The first time returns an interrupt error, while the second time prints 17.

Versions and Environment

Wasmtime version or commit: 0.38.1

Operating system: Linux

Architecture: x86-65

view this post on Zulip Wasmtime GitHub notifications bot (Jun 28 2022 at 02:47):

JMS55 opened issue #4342:

Test Case

https://github.com/JMS55/wasmtime-epoch-test

Steps to Reproduce

Expected Results

For it to print 17 both times. I expect that if I don't set an epoch deadline, then the code won't ever get interrupted.

Actual Results

The first time returns an interrupt error, while the second time prints 17.

Versions and Environment

Wasmtime version or commit: 0.38.1

Operating system: Linux

Architecture: x86-65

view this post on Zulip Wasmtime GitHub notifications bot (Jun 28 2022 at 02:58):

cfallin commented on issue #4342:

Without biasing one way or another, I'll just note that "default deadline is 0 ticks away" and "default deadline is +inf ticks away" are both kind of plausible, though I do agree that the latter is a bit less surprising.

I took a look at the documentation here and it seems that we don't actually say what happens if set_epoch_deadline is never called; so, strictly speaking, this is not a bug but perhaps failing to raise an error of the form "deadline never set!" is a bug. Alternately, perhaps we should default to +inf (no deadline), as you suggest.

I think the "semantic etymology" (if that's a thing) of this behavior probably traces back to fuel: by default one has no fuel, and one has to insert fuel to allow some execution. Here the default state is the same as the state after the thing has interrupted and returned to you once (deadline past, in either case); there's a nice symmetry to it. But that's certainly a subjective argument and not binding at all. I could go either way.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 28 2022 at 03:08):

JMS55 commented on issue #4342:

I don't feel that it is symmetric to fuel. Fuel says "you must pay X fuel per Y instruction, and cannot execute code if you can't pay". Epoch interrupts say "if you go past a scheduled point, stop".

Therefore, if you never schedule a deadline, there shouldn't be one. I thought that the default deadline would be None, not Some(0). Whereas with fuel, the default is 0 fuel (and the docs call this out explicitly), and you must first "load up" fuel for your program to run.

That said, I've just realized I have a bug in my program. I was intending to time only a portion of the code, but I can't trust that the setup code is not malicious either. I will have to set a deadline at the very start of the instance, anyways. Perhaps it _does_ make sense to have a default deadline of 0, to prevent cases like this.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 28 2022 at 03:08):

JMS55 edited a comment on issue #4342:

I don't feel that it is symmetric to fuel. Fuel says "you must pay X fuel per Y instruction, and cannot execute code if you can't pay". Epoch interrupts say "if you go past a scheduled point, stop".

Therefore, if you never schedule a deadline, there shouldn't be one. I thought that the default deadline would be None, not Some(0). Whereas with fuel, the default is 0 fuel (and the docs call this out explicitly), and you must first "load up" fuel for your program to run.

That said, I've just realized I have a bug in my program. I was intending to time only a portion of the code, but I can't trust that the setup code is not malicious either. I will have to set a deadline at the very start of the instance, anyways. Perhaps it _does_ make sense to have a default deadline of 0, to prevent cases like this. Either way, we should explicitly document the default.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 28 2022 at 15:13):

alexcrichton commented on issue #4342:

I was probably the origin of the default-trap behavior, and my thinking is that between the two possible defaults (trap never and trap immediately) the "trap never" default seems like it's always a bug if left because if epochs are configured you almost surely want the epoch to lapse at some point. I don't think the "trap immediately" behavior is wanted by anyone either, but it's a more obvious bug to fix than never trapping.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 28 2022 at 16:29):

alexcrichton closed issue #4342:

Test Case

https://github.com/JMS55/wasmtime-epoch-test

Steps to Reproduce

Expected Results

For it to print 17 both times. I expect that if I don't set an epoch deadline, then the code won't ever get interrupted.

Actual Results

The first time returns an interrupt error, while the second time prints 17.

Versions and Environment

Wasmtime version or commit: 0.38.1

Operating system: Linux

Architecture: x86-65

Last updated: Nov 22 2024 at 16:03 UTC