Changes look good to me, but I'd like to spend some time testing them out. In the meantime, if you could try to come up with a test case so we could have some coverage here that would help a great deal. This can be especially difficult for wasm but it's worth a shot. You may be able to mimic the allocation pattern that causes the failure in a new fixture grammar's external scanner. There are some examples you can work off of in crates/cli/src/tests/wasm_language_tests.rs (in particular, loading a fixture grammar in test_load_fixture_language_wasm).

Changes look good to me, but I'd like to spend some time testing them out. In the meantime, if you could try to come up with a test case so we could have some coverage here that would help a great deal. This can be especially difficult for wasm but it's worth a shot. You may be able to mimic the allocation pattern that causes the failure in a new fixture grammar's external scanner. There are some examples you can work off of in crates/cli/src/tests/wasm_language_tests.rs (in particular, loading a fixture grammar in test_load_fixture_language_wasm).

Sorry, I can't reproduce this in testing

Changes look good to me, but I'd like to spend some time testing them out. In the meantime, if you could try to come up with a test case so we could have some coverage here that would help a great deal. This can be especially difficult for wasm but it's worth a shot. You may be able to mimic the allocation pattern that causes the failure in a new fixture grammar's external scanner. There are some examples you can work off of in crates/cli/src/tests/wasm_language_tests.rs (in particular, loading a fixture grammar in test_load_fixture_language_wasm).

Sorry, I can't reproduce this in testing

I'll spend some time trying to come up with one when I have a chance then.

CC @maxbrunsfeld if you have a minute. Are the free calls added to realloc here ok? I'm assuming they were left out because the free implementation pre- 69c4245 didn't re-use free'd blocks in most cases, so it made sense to "leak" then. Given that's been updated, is there any reason to not free when appropriate in realloc now?

CC @maxbrunsfeld if you have a minute. Are the free calls added to realloc here ok? I'm assuming they were left out because the free implementation pre- 69c4245 didn't re-use free'd blocks in most cases, so it made sense to "leak" then. Given that's been updated, is there any reason to not free when appropriate in realloc now?

Since #5205 (comment) I never be able to connect the dots how wasm32 grammer file works, do you create a new wasm instance for each parsing so free in realloc is not necessary?