|
Revision tags: dev, v36.0.9, v44.0.1, v43.0.2, v36.0.8, v24.0.8, v44.0.0, v43.0.1, v42.0.2, v36.0.7, v24.0.7, v43.0.0, v42.0.1, v41.0.4, v42.0.0, v40.0.4, v36.0.6, v24.0.6, v41.0.3, v41.0.2, v41.0.1, v36.0.5, v40.0.3, v41.0.0, v36.0.4, v39.0.2, v40.0.2, v40.0.1, v40.0.0, v39.0.1, v39.0.0, v38.0.4, v37.0.3, v36.0.3, v24.0.5, v38.0.3, v38.0.2, v38.0.1, v37.0.2, v37.0.1, v37.0.0, v36.0.2, v36.0.1, v36.0.0, v35.0.0, v24.0.4, v33.0.2, v34.0.2, v34.0.1, v33.0.1, v24.0.3, v32.0.1, v34.0.0, v33.0.0, v32.0.0 |
| #
42bb677f |
| 31-Mar-2025 |
Alex Crichton <[email protected]> |
Improve errors with pooling-by-default `serve` command (#10483)
* Improve errors with pooling-by-default `serve` command
This commit is intended to address #10482 where the defaults of the
`wasmtim
Improve errors with pooling-by-default `serve` command (#10483)
* Improve errors with pooling-by-default `serve` command
This commit is intended to address #10482 where the defaults of the
`wasmtime serve` subcommand produced a confusing and surprising error.
Specifically the `-Wmax-table-elements` option, prior to this change, only
affected the store limiter used and didn't actually affect the pooling
allocator settings. That meant that if a module exceeded the limits of
the pooling allocator it would produce an error message that seemed like
`-Wmax-table-elements` would fix but it wouldn't actually.
Two changes in this commit are meant to address this:
* Errors from the pooling allocator have been update to mention "pooling
allocator" within them somewhere to surface where the error is coming
from.
* The `-Wmax-memory-size` and `-Wmax-table-elements` configuration are
now applied to the pooling allocator automatically if the
corresponding `-Opooling-*` option isn't passed.
That should mean that the original error should be a bit easier to debug
while the attempted solution will also work.
* Fix test expectations
* Get new test passing on 32-bit
show more ...
|