wasmtime / PR #14555 fix over-eager deletion of task grou... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #14555 fix over-eager deletion of task grou...

Wasmtime GitHub notifications bot (Oct 05 2026 at 21:54):

dicej requested alexcrichton for a review on PR #14555.

Wasmtime GitHub notifications bot (Oct 05 2026 at 21:54):

dicej opened PR #14555 from dicej:fix-14504 to bytecodealliance:main:

Instead of deleting any outstanding task groups when trapping, we now just record that we've notified the task hook so we don't do it again if and when the group's ref count goes to zero.

Fixes #14504

Wasmtime GitHub notifications bot (Oct 05 2026 at 21:54):

dicej requested wasmtime-core-reviewers for a review on PR #14555.

Wasmtime GitHub notifications bot (Oct 05 2026 at 21:59):

:memo: alexcrichton submitted PR review:

I'm a bit confused by how this works -- the finished field is never set to true while the groups are in the table, except when the store is torn down. Was this a problem where during teardown the same group was deleted twice? If so could that be solved by reordering some teardown?

Wasmtime GitHub notifications bot (Oct 05 2026 at 21:59):

:speech_balloon: alexcrichton created PR review comment:

leftover debugging?

Wasmtime GitHub notifications bot (Oct 05 2026 at 22:03):

dicej updated PR #14555.

Wasmtime GitHub notifications bot (Oct 05 2026 at 22:12):

dicej commented on PR #14555:

I'm a bit confused by how this works -- the finished field is never set to true while the groups are in the table, except when the store is torn down. Was this a problem where during teardown the same group was deleted twice? If so could that be solved by reordering some teardown?

clean_up_task_groups is called in two places: when a store is poisoned due to a trap and when it is disposed. In either case, the may be other cleanup after that call completes (e.g. gracefully disposing of fibers, etc.) which may cause guest and/or host tasks to be disposed, in which case we may try to look up the task group for those tasks to dispose it, but since clean_up_task_groups had already deleted the group, we errored, and that error was escalated to a panic in SignalOnDrop::drop.

Wasmtime GitHub notifications bot (Oct 05 2026 at 23:39):

alexcrichton commented on PR #14555:

Do we need to run this on set_trapped? Would it be possible to only run this on store teardown?

Wasmtime GitHub notifications bot (Oct 06 2026 at 01:16):

github-actions[bot] added the label wasmtime:api on PR #14555.

Wasmtime GitHub notifications bot (Oct 06 2026 at 12:54):

dicej commented on PR #14555:

Do we need to run this on set_trapped? Would it be possible to only run this on store teardown?

No, we don't have to; I figured it would be best to do it promptly, but I'd be fine with only doing it on store teardown. And note that we'd have to make sure it's pretty much the last thing we do on store teardown if we want to delete any task groups before their reference counts go to zero; otherwise, we'll risk hitting this issue again.