<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in big_table.wat</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>42bb677f - Improve errors with pooling-by-default `serve` command (#10483)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/cli_tests/big_table.wat#42bb677f</link>
        <description>Improve errors with pooling-by-default `serve` command (#10483)* Improve errors with pooling-by-default `serve` commandThis 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, onlyaffected the store limiter used and didn&apos;t actually affect the poolingallocator settings. That meant that if a module exceeded the limits ofthe pooling allocator it would produce an error message that seemed like`-Wmax-table-elements` would fix but it wouldn&apos;t actually.Two changes in this commit are meant to address this:* Errors from the pooling allocator have been update to mention &quot;pooling  allocator&quot; 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&apos;t passed.That should mean that the original error should be a bit easier to debugwhile the attempted solution will also work.* Fix test expectations* Get new test passing on 32-bit

            List of files:
            /wasmtime-44.0.1/tests/all/cli_tests/big_table.wat</description>
        <pubDate>Mon, 31 Mar 2025 17:55:54 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
</channel>
</rss>
