Stream: git-wasmtime

Topic: wasmtime / Issue #2751 resource limit exceeded: instance ...

Wasmtime GitHub notifications bot (Mar 22 2021 at 15:07):

bxq2011hust opened Issue #2751:

I use one module to wasm_instance_new(C-API) instance to execute the function to save the cost of wasm_module_new, at start it works well, After some time running, I can't use wasm_instance_new to create new instance and got the error message resource limit exceeded: instance count too high at 10001. But I freed the instance use wasm_instance_delete every time execution is done, also free the exports. Is there some way to use one module to create instances more than 10000 times?

Wasmtime GitHub notifications bot (Mar 22 2021 at 15:09):

bxq2011hust edited Issue #2751:

I use one module to wasm_instance_new(C-API) instance to execute the function to save the cost of wasm_module_new, at start it works well, After some time running, I can't use wasm_instance_new to create new instance and got the error message resource limit exceeded: instance count too high at 10001.
I freed the instance use wasm_instance_delete every time execution is done, also free the exports, I think the count of instance should decrease to zero after execution, It seems the count of instance is cumulative. Is there some way to use one module to create instances more than 10000 times?

Wasmtime GitHub notifications bot (Mar 22 2021 at 15:34):

bjorn3 commented on Issue #2751:

You can use wasmtime_config_max_instances_set which gets a wasm_config_t* and size_t as argument.

https://github.com/bytecodealliance/wasmtime/blob/6e6713ae0b0be578221a2802719327526458a8cf/crates/c-api/include/wasmtime.h#L292

Wasmtime GitHub notifications bot (Mar 22 2021 at 15:34):

bjorn3 edited a comment on Issue #2751:

You can use wasmtime_config_max_instances_set which gets a wasm_config_t* and size_t as argument.

https://github.com/bytecodealliance/wasmtime/blob/6e6713ae0b0be578221a2802719327526458a8cf/crates/c-api/include/wasmtime.h#L286-L292

Wasmtime GitHub notifications bot (Mar 22 2021 at 17:50):

alexcrichton commented on Issue #2751:

It's important to note that wasm_instance_delete does not actually delete the underlying instance's resources, just the C object representing the instance. I don't think we have a ton of documentation for this but an instance's resources are only deallocated when the entire Store (or wasm_store_t) goes away. This means that for a long-lived use case you likely want a singular wasm_engine_t and the wasm_store_t should be ephemeral and not as long-lived.

Otherwise though, if you'd like to do this, 10000 is just the default and as mentioned you can up the limit yourself.

Wasmtime GitHub notifications bot (Mar 23 2021 at 01:37):

bxq2011hust commented on Issue #2751:

@bjorn3 thank you very much, I read the WASMTIME_CONFIG_PROP(void, max_instances, size_t) , this can allow me to create more instance use one module.
Also, I found wasmtime_store_gc in wasmtime.h, I wonder if I can use wasmtime_store_gc to decrease the store's count of the instance before it reaches the max_instances so that I can use one module to create instances always?

Wasmtime GitHub notifications bot (Mar 23 2021 at 01:57):

bxq2011hust commented on Issue #2751:

@alexcrichton ok, I see. Is wasmtime_store_gc can release the instance's resource?:thinking:️

If the wasmtime_store_gc can't release the instance's resource then I will consider recreating the wasm_engine_t and the wasm_store_t before it reaches 10000.

Wasmtime GitHub notifications bot (Mar 23 2021 at 02:00):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton ok, I see, thanks. Is wasmtime_store_gc can release the instance's resource?:thinking:️

If the wasmtime_store_gc can't release the instance's resource then I will consider recreating the wasm_engine_t and the wasm_store_t before it reaches 10000.

Wasmtime GitHub notifications bot (Mar 23 2021 at 02:13):

peterhuene commented on Issue #2751:

@bxq2011hust wasmtime_store_gc is used to perform a garbage collection of externref values that may no longer be reachable; it has no relationship to instances and only has relevance if you're passing externref values into WebAssembly code.

In Wasmtime, a module has no relation to a store, so you can also use wasmtime_module_new which better encapsulates this (the store passed to wasm_module_new is only used to get the related engine).

As module and engine have no relation to store, you may continue to use them after any calls to wasm_store_delete; thus you may create a new store each time you wish to instantiate your module.

Wasmtime GitHub notifications bot (Mar 23 2021 at 02:14):

peterhuene edited a comment on Issue #2751:

@bxq2011hust wasmtime_store_gc is used to perform a garbage collection of externref values that may no longer be reachable; it has no relationship to instances and only has relevance if you're passing externref values into WebAssembly code.

In Wasmtime, a module has no relation to a store, so you can also use wasmtime_module_new which better encapsulates this (the store passed to wasm_module_new is only used to get the related engine).

As module and engine have no relation to store, you may continue to use them after any calls to wasm_store_delete; thus you may create a new store each time you wish to instantiate your module. This should help prevent you reaching any sort of limits by reusing a store for multiple instantiations.

Wasmtime GitHub notifications bot (Mar 23 2021 at 02:14):

peterhuene edited a comment on Issue #2751:

@bxq2011hust wasmtime_store_gc is used to perform a garbage collection of externref values that may no longer be reachable; it has no relationship to instances and only has relevance if you're passing externref values into WebAssembly code.

In Wasmtime, a module has no relation to a store, so you can also use wasmtime_module_new which better encapsulates this (the store passed to wasm_module_new is only used to get the related engine).

As module and engine have no relation to store, you may continue to use them after any calls to wasm_store_delete; thus you may create a new store each time you wish to instantiate your module. This should help prevent you from reaching any sort of limits by not reusing a store for multiple instantiations.

Wasmtime GitHub notifications bot (Mar 23 2021 at 04:36):

bxq2011hust commented on Issue #2751:

@peterhuene yes, that's what I want. I tried your idea and it worked, thanks!!!:big_smile::big_smile:

Wasmtime GitHub notifications bot (Mar 23 2021 at 04:51):

peterhuene commented on Issue #2751:

@bxq2011hust may I close this issue if your problem has been resolved?

Wasmtime GitHub notifications bot (Mar 23 2021 at 04:56):

bxq2011hust commented on Issue #2751:

@peterhuene Last question. In the https://github.com/WebAssembly/wasm-c-api, it said

All runtime objects are tied to a specific store (wasm::Store/wasm_store_t). Multiple stores can be created, but their objects cannot interact. Every store and its objects must only be accessed in a single thread.
It seems in one thread I need a new instance, and I surely do that now. I want to save the time cost of creating imports of function and the time of creating new instances by use one instance in multi-thread. I want to know if I call wasm_func_call with the same instance in multi-threads is it ok of the wasmtime engine?

Wasmtime GitHub notifications bot (Mar 23 2021 at 04:56):

bxq2011hust edited a comment on Issue #2751:

@peterhuene Last question. In the https://github.com/WebAssembly/wasm-c-api, it said

All runtime objects are tied to a specific store (wasm::Store/wasm_store_t). Multiple stores can be created, but their objects cannot interact. Every store and its objects must only be accessed in a single thread.

It seems in one thread I need a new instance, and I surely do that now. I want to save the time cost of creating imports of function and the time of creating new instances by use one instance in multi-thread. I want to know if I call wasm_func_call with the same instance in multi-threads is it ok of the wasmtime engine?

Wasmtime GitHub notifications bot (Mar 23 2021 at 04:57):

bxq2011hust edited a comment on Issue #2751:

@peterhuene Last question. In the https://github.com/WebAssembly/wasm-c-api, it said

All runtime objects are tied to a specific store (wasm::Store/wasm_store_t). Multiple stores can be created, but their objects cannot interact. Every store and its objects must only be accessed in a single thread.

It seems in one thread I need a new instance, and I surely do that now. I want to save the time cost of creating imports of functions and the time of creating new instances by use one instance in multi-thread. I want to know if I call wasm_func_call with the same instance in multi-threads is it ok of the wasmtime engine?

Wasmtime GitHub notifications bot (Mar 23 2021 at 04:58):

bxq2011hust edited a comment on Issue #2751:

@peterhuene Last question. In the https://github.com/WebAssembly/wasm-c-api, it said

All runtime objects are tied to a specific store (wasm::Store/wasm_store_t). Multiple stores can be created, but their objects cannot interact. Every store and its objects must only be accessed in a single thread.

It seems in one thread I need a new instance, and I surely do that now. I want to save the time cost of creating imports of functions and the time of creating new instances by use one instance in multi-thread. I want to know if I call wasm_func_call with the same instance in multi-threads is it ok of the wasmtime engine?

Although according to the document, this is not allowed. :pensive:

Wasmtime GitHub notifications bot (Mar 23 2021 at 09:10):

bxq2011hust edited a comment on Issue #2751:

@peterhuene Last question. In the https://github.com/WebAssembly/wasm-c-api, it said

All runtime objects are tied to a specific store (wasm::Store/wasm_store_t). Multiple stores can be created, but their objects cannot interact. Every store and its objects must only be accessed in a single thread.

It seems in one thread I need a new instance, and I surely do that now. I want to save the time cost of creating imports of functions and the time of creating new instances by use one instance in multi-thread. I want to know if I call wasm_func_call with the same instance in multi-threads is it ok of the wasmtime engine?

Although according to the document, this is not allowed. :pensive:
ok, I tried use one instance in multi-thread, failed. I need to try to cache some instances to improve performance.

Thank you very much for your reply! wasmtime is great!

Wasmtime GitHub notifications bot (Mar 23 2021 at 09:10):

bxq2011hust edited a comment on Issue #2751:

@peterhuene Last question. In the https://github.com/WebAssembly/wasm-c-api, it said

All runtime objects are tied to a specific store (wasm::Store/wasm_store_t). Multiple stores can be created, but their objects cannot interact. Every store and its objects must only be accessed in a single thread.

It seems in one thread I need a new instance, and I surely do that now. I want to save the time cost of creating imports of functions and the time of creating new instances by use one instance in multi-thread. I want to know if I call wasm_func_call with the same instance in multi-threads is it ok of the wasmtime engine?

Although according to the document, this is not allowed. :pensive:
ok, I tried use one instance in multi-thread, failed. Maybe I should try to cache some instances to improve performance.

Thank you very much for your reply! wasmtime is great!

Wasmtime GitHub notifications bot (Mar 23 2021 at 09:10):

bxq2011hust edited a comment on Issue #2751:

@peterhuene Last question. In the https://github.com/WebAssembly/wasm-c-api, it said

All runtime objects are tied to a specific store (wasm::Store/wasm_store_t). Multiple stores can be created, but their objects cannot interact. Every store and its objects must only be accessed in a single thread.

It seems in one thread I need a new instance, and I surely do that now. I want to save the time cost of creating imports of functions and the time of creating new instances by use one instance in multi-thread. I want to know if I call wasm_func_call with the same instance in multi-threads is it ok of the wasmtime engine?

Although according to the document, this is not allowed. :pensive:
ok, I tried using one instance in multi-thread, failed. Maybe I should try to cache some instances to improve performance.

Thank you very much for your reply! wasmtime is great!

Wasmtime GitHub notifications bot (Mar 23 2021 at 15:33):

alexcrichton commented on Issue #2751:

It is not safe to wasm_func_call the same function on multiple threads, all objects connected to wasm_store_t (which includes wasm_func_t) must be used on only one thread at a time.

The Rust wasmtime crate has the ability to define functions in the Engine-scope to share them across stores -- https://docs.rs/wasmtime/0.25.0/wasmtime/struct.Config.html#method.define_host_func -- but this is not currently exposed in the C API.

Wasmtime GitHub notifications bot (Mar 24 2021 at 02:15):

bxq2011hust commented on Issue #2751:

It is not safe to wasm_func_call the same function on multiple threads, all objects connected to wasm_store_t (which includes wasm_func_t) must be used on only one thread at a time.

The Rust wasmtime crate has the ability to define functions in the Engine-scope to share them across stores -- https://docs.rs/wasmtime/0.25.0/wasmtime/struct.Config.html#method.define_host_func -- but this is not currently exposed in the C API.

Ok, get it, thanks:blush: . A little suggestion, if the cache config has an API to config it may be more convenient, like

WASMTIME_CONFIG_PROP(void, enable_cache, wasm_config_t*, const char* , size_t, size_t);
WASMTIME_CONFIG_PROP(void, disable_cache, wasm_config_t*);

https://github.com/bytecodealliance/wasmtime/blob/6e6713ae0b0be578221a2802719327526458a8cf/crates/c-api/include/wasmtime.h#L306

I use wasmtime as a library to offer wasm runtime in my library, it's not convenient for my library to create a toml file to use cache.

Again, thanks you guys for your help.

Wasmtime GitHub notifications bot (Mar 24 2021 at 02:15):

bxq2011hust closed Issue #2751:

I use one module to wasm_instance_new(C-API) instance to execute the function to save the cost of wasm_module_new, at start it works well, After some time running, I can't use wasm_instance_new to create new instance and got the error message resource limit exceeded: instance count too high at 10001.
I freed the instance use wasm_instance_delete every time execution is done, also free the exports, I think the count of instance should decrease to zero after execution, It seems the count of instance is cumulative. Is there some way to use one module to create instances more than 10000 times?

Wasmtime GitHub notifications bot (Mar 24 2021 at 02:16):

bxq2011hust edited a comment on Issue #2751:

It is not safe to wasm_func_call the same function on multiple threads, all objects connected to wasm_store_t (which includes wasm_func_t) must be used on only one thread at a time.

The Rust wasmtime crate has the ability to define functions in the Engine-scope to share them across stores -- https://docs.rs/wasmtime/0.25.0/wasmtime/struct.Config.html#method.define_host_func -- but this is not currently exposed in the C API.

Ok, get it, thanks:blush: . A little suggestion, if the cache config has an API to config it may be more convenient, like

WASMTIME_CONFIG_PROP(void, enable_cache, wasm_config_t*, const char* , size_t, size_t);
WASMTIME_CONFIG_PROP(void, disable_cache, wasm_config_t*);

https://github.com/bytecodealliance/wasmtime/blob/6e6713ae0b0be578221a2802719327526458a8cf/crates/c-api/include/wasmtime.h#L306

I use wasmtime as a library to offer wasm runtime in my library, it's not convenient for my library to create a toml file to use cache.

Again, thanks you guys for your help!

Wasmtime GitHub notifications bot (Mar 24 2021 at 08:38):

bxq2011hust commented on Issue #2751:

@alexcrichton I create a pool of instances, each instance has its own store, when a request is arrived, get an instance to process, but I failed with EXC_BAD_ACCESS. Is it possible to reuse an instance(the first use and next maybe in different thread, but each instance is used by one thread at the same time)?

Wasmtime GitHub notifications bot (Mar 24 2021 at 08:38):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton Hi, I create a pool of instances, each instance has its own store, when a request is arrived, get an instance to process, but I failed with EXC_BAD_ACCESS. Is it possible to reuse an instance(the first use and next maybe in different thread, but each instance is used by one thread at the same time)?

Wasmtime GitHub notifications bot (Mar 24 2021 at 08:40):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton Hi, I create a pool of instances, each instance has its own store, when a request is arrived, get an instance to process, but I failed with EXC_BAD_ACCESS. Is it possible to reuse an instance(the first use and next maybe in different thread, but each instance is used by one thread at the same time)?
I found some discuss in #2295 , but not answered my question

Wasmtime GitHub notifications bot (Mar 24 2021 at 08:41):

bxq2011hust reopened Issue #2751:

I use one module to wasm_instance_new(C-API) instance to execute the function to save the cost of wasm_module_new, at start it works well, After some time running, I can't use wasm_instance_new to create new instance and got the error message resource limit exceeded: instance count too high at 10001.
I freed the instance use wasm_instance_delete every time execution is done, also free the exports, I think the count of instance should decrease to zero after execution, It seems the count of instance is cumulative. Is there some way to use one module to create instances more than 10000 times?

Wasmtime GitHub notifications bot (Mar 24 2021 at 08:48):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton Hi, In my use case, I will call an export function of the instance with different parameters many times, so if I can reuse instance, then I can save the cost of creating instance and imports, with a pool of instances I can parallel to preocess the call request.
So I create a pool of instances, each instance has its own store, when a request is arrived, get an instance to process, but I failed with EXC_BAD_ACCESS.
Is it possible to reuse an instance(the first use and next maybe in different thread, but each instance is used by one thread at the same time)?

I found some discuss in #2295 , but not answered my question

Wasmtime GitHub notifications bot (Mar 24 2021 at 08:50):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton Hi, In my use case, I will call an export function of the instance with different parameters many times, so if I can reuse instance, then I can save the cost of creating instance and imports, with a pool of instances I can parallel to preocess the call request.
So I create a pool of instances, each instance has its own store, when a request is arrived, a thread will try to get an idle instance to process, if there isn't an idle instance then create one, but I failed with the EXC_BAD_ACCESS.
Is it possible to reuse an instance(the first use and next maybe in different thread, but each instance is used by one thread at the same time)?

I found some discuss in #2295 , but not answered my question

Wasmtime GitHub notifications bot (Mar 24 2021 at 08:50):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton Hi, In my use case, I will call an export function of the instance with different parameters many times, so if I can reuse instance, then I can save the cost of creating instance and imports, with a pool of instances I can parallel to preocess the call request.
So I create a pool of instances, each instance has its own store, when a request is arrived, a thread will try to get an idle instance to process, if there isn't an idle instance then create one, but I failed with the EXC_BAD_ACCESS.
I wonder if it is possible to reuse an instance(the first use and next maybe in different thread, but each instance is used by one thread at the same time)?

I found some discuss in #2295 , but not answered my question

Wasmtime GitHub notifications bot (Mar 24 2021 at 14:13):

alexcrichton commented on Issue #2751:

Yes a strategy such as that should be safe to use from Wasmtime. You have to be sure, though, that everything connected to a store moves as a single unit between threads. If an instance is used on multiple threads over its lifetime, though, that's fine.

If you're getting faults with that strategy, though, can you gist the code you're working with so we can reproduce and investigate?

Wasmtime GitHub notifications bot (Mar 24 2021 at 15:40):

bxq2011hust commented on Issue #2751:

@alexcrichton Thank you very much, it is a bug in my code. The env of function closure is invalid after execution and I forget to update the env pointer before the next execution.:face_palm:‍♂️ Now it works well! 😄

Wasmtime GitHub notifications bot (Mar 25 2021 at 03:37):

bxq2011hust commented on Issue #2751:

@alexcrichton Hi, I come back again. I meet a new problem, the instance works well before it is used under 109 times, but I try to use the instance again, I get EXC_BAD_ACCESS. I guess the instance has some limit(memory, stack of something), the below what I see. Do you have any ideas?

Wasmtime GitHub notifications bot (Mar 25 2021 at 03:47):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton Hi, I come back again. I meet a new problem, the instance works well before it is used under 109 times, but I try to use the instance again, I get EXC_BAD_ACCESS. I guess the instance has some limit(memory, stack or something), the below what I see. Do you have any ideas?

Wasmtime GitHub notifications bot (Mar 25 2021 at 04:21):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton Hi, I come back again. I meet a new problem, the instance works well before it is used under 109 times, but I try to use the instance again, I get EXC_BAD_ACCESS. I guess the instance has some limit(memory, stack or something), the below is what I see. Do you have any ideas?

Wasmtime GitHub notifications bot (Mar 25 2021 at 06:10):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton Hi, I come back again. I meet a new problem, the instance works well before it is used less than 109 times, but I try to use the instance again, I get EXC_BAD_ACCESS. I guess the instance has some limit(memory, stack or something), the below is what I see. Do you have any ideas?

Wasmtime GitHub notifications bot (Mar 25 2021 at 10:09):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton Hi, I come back again. I meet a new problem, the instance works well before it is used less than 109 times, but I try to use the instance again, I get EXC_BAD_ACCESS. I call another function in wasm always ok. Are there some tools to help me profile?
I guess the instance has some limit(memory, stack or something), the below is what I see. Do you have any ideas?


Wasmtime GitHub notifications bot (Mar 25 2021 at 10:11):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton Hi, I come back again. I meet a new problem, the instance works well before it is used less than 109 times, but I try to use the instance again, I get EXC_BAD_ACCESS. I call another function in wasm always ok. Are there some tools to help me profile? https://github.com/bxq2011hust/hera/blob/dev-liquid-asset/src/wasmc.cpp#L1280-L1691
I guess the instance has some limit(memory, stack or something), the below is what I see. Do you have any ideas?


Wasmtime GitHub notifications bot (Mar 25 2021 at 10:12):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton Hi, I come back again. I meet a new problem, the instance works well before it is used less than 109 times, but I try to use the instance again, I get EXC_BAD_ACCESS. I call another function in wasm always ok. Are there some tools to help me profile? here is the code how I use wasmtime to make instances pool.
I guess the instance has some limit(memory, stack or something), the below is what I see. Do you have any ideas?


Wasmtime GitHub notifications bot (Mar 25 2021 at 10:15):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton Hi, I come back again. I meet a new problem, the instance works well before it is used less than 109 times, but I try to use the instance again, I get EXC_BAD_ACCESS. I call another function in wasm always ok. Are there some tools to help me profile? here is the code how I use wasmtime to make instances pool. I even tried wasmer, get the same issue,
I guess the instance has some limit(memory, stack or something), the below is what I see. Do you have any ideas?


Wasmtime GitHub notifications bot (Mar 25 2021 at 10:15):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton Hi, I come back again. I meet a new problem, the instance works well before it is used less than 109 times, but I try to use the instance again, I get EXC_BAD_ACCESS. I call another function in wasm always ok. Are there some tools to help me profile? here is the code how I use wasmtime to make instances pool. I even tried wasmer, get the same issue, alsoRegisterSetjmp and EXC_BAD_ACCESS.
I guess the instance has some limit(memory, stack or something), the below is what I see. Do you have any ideas?


Wasmtime GitHub notifications bot (Mar 25 2021 at 14:13):

alexcrichton commented on Issue #2751:

I'd recommend trying to use valgrind or perhaps thread sanitizers in C++, otherwise nothing looks too obviously awry from a quick scan. Otherwise the most useful thing I think would be to try to reduce it to a smaller program to help narrow in on what the problem is.

Instances shouldn't have limits which poison them after some use, unless they're incorrectly cleaned up, which doesn't look like it's the case there I think.

Wasmtime GitHub notifications bot (Mar 26 2021 at 05:54):

bxq2011hust commented on Issue #2751:

@alexcrichton I try to use algrind trace the bug, the below is results.


I think that the bug is in the wasm I used, there has an illegal memory access happened in the wasm, I also get out of bounds memory access in the trap.


Wasmtime GitHub notifications bot (Mar 26 2021 at 06:08):

bxq2011hust commented on Issue #2751:

@alexcrichton It seems if i use linear memory in wasm and the function F in wasm exit by call host function to return a trap, the memory allocated by the F is not freed, then the next time call the F the memory usage of instance will grow. The wasm binary I used is optimized, maybe the optimized make the F not grow memory, so after many times call F the memory is out of bounds.
Is there some way to release all linear memory of an instance? Or maybe there is a better way to interrupt the execution?

Wasmtime GitHub notifications bot (Mar 26 2021 at 06:19):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton It seems if i use linear memory in wasm and the function F in wasm exit by call host function to return a trap, the memory allocated by the F is not freed, then the next time call the F the memory usage of instance will grow. The wasm binary I used is optimized, maybe the optimization makes the F can't grow memory, so after many times call F the memory is out of bounds.
Is there some way to reset the linear memory of an instance after each execution? Or maybe there is a better way to interrupt the execution and release the memory at the same time?

Wasmtime GitHub notifications bot (Mar 26 2021 at 06:51):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton It seems if i use linear memory in wasm and the function F in wasm exit by call host function to return a trap, the memory allocated by the F is not freed, then the next time call the F the memory usage of instance will grow. The wasm binary I used is optimized, maybe the optimization makes the F can't grow memory, so after many times call F the memory is out of bounds.
Is there some way to reset the linear memory of an instance after each execution? Or maybe there is a better way to interrupt the execution and release the memory at the same time?

I found wasmtime_interrupt_handle_interrupt, the wasmtime_interrupt_handle should call from another thread? Can I call it in host function called by wasm? If I call wasmtime_interrupt_handle will the linear memory be reset ?

Wasmtime GitHub notifications bot (Mar 26 2021 at 07:27):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton It seems if i use linear memory in wasm and the function F in wasm exit by call host function to return a trap, the memory allocated by the F is not freed, then the next time call the F the memory usage of instance will grow. The wasm binary I used is optimized, maybe the optimization makes the F can't grow memory always or the way stop execution creates too many traps, so after many times call F the memory is out of bounds.
Is there some way to reset the linear memory of an instance after each execution? Or maybe there is a better way to interrupt the execution and release the memory at the same time?

I found wasmtime_interrupt_handle_interrupt, the wasmtime_interrupt_handle should call from another thread? Can I call it in host function called by wasm? If I call wasmtime_interrupt_handle will the linear memory be reset ?

Wasmtime GitHub notifications bot (Mar 26 2021 at 07:43):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton It seems if I use linear memory in wasm and the function F in wasm exit by call host function to return a trap, the memory allocated by the F is not freed, then the next time calls the F the memory usage of instance will grow. I guess either the way stop execution makes troubles, or the wasm I used has bugs in manage linear memory.

Is there some way to reset the state of an instance after each execution? Or maybe there is a better way to interrupt the execution elegant?

I found wasmtime_interrupt_handle_interrupt, the wasmtime_interrupt_handle should call from another thread? Can I call it in the host function called by wasm? If I call wasmtime_interrupt_handle will the linear memory be reset?

Wasmtime GitHub notifications bot (Mar 26 2021 at 09:28):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton It seems if I use linear memory in wasm and the function F in wasm exit by call host function to return a trap, the memory allocated by the F is not freed, then the next time calls the F the memory usage of instance will grow. I guess either the way stop execution makes troubles, or the wasm I used has bugs in manage linear memory.

Is there some way to reset the state of an instance after each execution? Or maybe there is a better way to interrupt the execution elegant?

call main, error message: wasm trap: out of bounds memory access
wasm backtrace:
    0: 0x8c73c - <unknown>!wee_alloc::FreeCell::try_alloc::hb2660e954f6e5223
    1: 0x8d3c7 - <unknown>!wee_alloc::alloc_first_fit::{{closure}}::hfd5f453a5b3dec0c
    2: 0x8d227 - <unknown>!wee_alloc::walk_free_list::hd831c341105a6b2d
    3: 0x8d596 - <unknown>!wee_alloc::alloc_first_fit::h7f42292292e49180
    4: 0x8d603 - <unknown>!wee_alloc::alloc_with_refill::h3525530d2d10e1ae
    5: 0x8da3f - <unknown>!wee_alloc::WeeAlloc::alloc_impl::{{closure}}::hd235f0224f501596
    6: 0x8d97f - <unknown>!wee_alloc::WeeAlloc::with_free_list_and_policy_for_size::{{closure}}::h1153d640b2b12f57
    7: 0x906ea - <unknown>!wee_alloc::imp_wasm32::Exclusive<T>::with_exclusive_access::hebe42350c45bd1b7
    8: 0x8d8bb - <unknown>!wee_alloc::WeeAlloc::with_free_list_and_policy_for_size::h06f3b976cadcd3c9
    9: 0x8df5e - <unknown>!wee_alloc::WeeAlloc::alloc_impl::hbd0790bc4271633f
   10: 0x8e169 - <unknown>!<wee_alloc::WeeAlloc as core::alloc::global::GlobalAlloc>::alloc::h366b133ed0c2cb3f
   11: 0x8b3c6 - <unknown>!__rg_alloc
   12: 0x47f5b - <unknown>!__rust_alloc
   13: 0x86f0f - <unknown>!alloc::alloc::alloc::hc87f001bc6c9f141
   14: 0x8702d - <unknown>!alloc::alloc::Global::alloc_impl::haa97078f3f34b5da
   15: 0x86e74 - <unknown>!<alloc::alloc::Global as core::alloc::Allocator>::allocate::hfa4575a09cbd1182
   16: 0x83d35 - <unknown>!alloc::raw_vec::RawVec<T,A>::allocate_in::h1570326482613819
   17: 0x85490 - <unknown>!alloc::raw_vec::RawVec<T,A>::with_capacity_in::h5abb55ecde21b81f
   18: 0x80d1c - <unknown>!alloc::vec::Vec<T,A>::with_capacity_in::hfafb52572c534d64
   19: 0x86c97 - <unknown>!<T as alloc::slice::hack::ConvertVec>::to_vec::hc813c591a8fa1bfd
   20: 0x87a10 - <unknown>!alloc::slice::hack::to_vec::hef5ce951d3ea8fbe
   21: 0x7bb8e - <unknown>!alloc::slice::<impl [T]>::to_vec_in::h885d10b1cfcd4103
   22: 0x7bb40 - <unknown>!alloc::slice::<impl [T]>::to_vec::h5083212bb2e14c81
   23: 0x25a43 - <unknown>!liquid_lang::lang_core::storage::cell::typed_cell::TypedCell<T>::new::ha7ebd5c4811cd7f3
   24: 0x138c2 - <unknown>!liquid_lang::lang_core::storage::cell::cached_cell::CachedCell<T>::new::h4093120e1570dec6
   25: 0xfd04 - <unknown>!<liquid_lang::lang_core::storage::value::Value<T> as liquid_lang::lang_core::storage::traits::Bind>::bind_with::hc390e7ecb7ed1422
   26: 0xa054 - <unknown>!<parallelok::parallel_ok::__liquid_private::__liquid_storage::Storage as liquid_lang::lang_core::storage::traits::New>::new::h2cc23a83c1212243
   27: 0xbadb - <unknown>!parallelok::parallel_ok::__liquid_private::_::<impl parallelok::parallel_ok::__liquid_private::__liquid_storage::Storage>::dispatch::h5004208c4c584335
   28: 0x34613 - <unknown>!main
note: run with `WASMTIME_BACKTRACE_DETAILS=1` environment variable to display more information

I found wasmtime_interrupt_handle_interrupt, the wasmtime_interrupt_handle should call from another thread? Can I call it in the host function called by wasm? If I call wasmtime_interrupt_handle will the linear memory be reset?

Wasmtime GitHub notifications bot (Mar 26 2021 at 09:29):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton It seems if I use linear memory in wasm and the function F in wasm exit by call host function to return a trap, the memory allocated by the F is not freed, then the next time calls the F the memory usage of instance will grow. I guess either the way stop execution makes troubles, or the wasm I used has bugs in manage linear memory.

call main, error message: wasm trap: out of bounds memory access
wasm backtrace:
    0: 0x8c73c - <unknown>!wee_alloc::FreeCell::try_alloc::hb2660e954f6e5223
    1: 0x8d3c7 - <unknown>!wee_alloc::alloc_first_fit::{{closure}}::hfd5f453a5b3dec0c
    2: 0x8d227 - <unknown>!wee_alloc::walk_free_list::hd831c341105a6b2d
    3: 0x8d596 - <unknown>!wee_alloc::alloc_first_fit::h7f42292292e49180
    4: 0x8d603 - <unknown>!wee_alloc::alloc_with_refill::h3525530d2d10e1ae
    5: 0x8da3f - <unknown>!wee_alloc::WeeAlloc::alloc_impl::{{closure}}::hd235f0224f501596
    6: 0x8d97f - <unknown>!wee_alloc::WeeAlloc::with_free_list_and_policy_for_size::{{closure}}::h1153d640b2b12f57
    7: 0x906ea - <unknown>!wee_alloc::imp_wasm32::Exclusive<T>::with_exclusive_access::hebe42350c45bd1b7
    8: 0x8d8bb - <unknown>!wee_alloc::WeeAlloc::with_free_list_and_policy_for_size::h06f3b976cadcd3c9
    9: 0x8df5e - <unknown>!wee_alloc::WeeAlloc::alloc_impl::hbd0790bc4271633f
   10: 0x8e169 - <unknown>!<wee_alloc::WeeAlloc as core::alloc::global::GlobalAlloc>::alloc::h366b133ed0c2cb3f
   11: 0x8b3c6 - <unknown>!__rg_alloc
   12: 0x47f5b - <unknown>!__rust_alloc
   13: 0x86f0f - <unknown>!alloc::alloc::alloc::hc87f001bc6c9f141
   14: 0x8702d - <unknown>!alloc::alloc::Global::alloc_impl::haa97078f3f34b5da
   15: 0x86e74 - <unknown>!<alloc::alloc::Global as core::alloc::Allocator>::allocate::hfa4575a09cbd1182
   16: 0x83d35 - <unknown>!alloc::raw_vec::RawVec<T,A>::allocate_in::h1570326482613819
   17: 0x85490 - <unknown>!alloc::raw_vec::RawVec<T,A>::with_capacity_in::h5abb55ecde21b81f
   18: 0x80d1c - <unknown>!alloc::vec::Vec<T,A>::with_capacity_in::hfafb52572c534d64
   19: 0x86c97 - <unknown>!<T as alloc::slice::hack::ConvertVec>::to_vec::hc813c591a8fa1bfd
   20: 0x87a10 - <unknown>!alloc::slice::hack::to_vec::hef5ce951d3ea8fbe
   21: 0x7bb8e - <unknown>!alloc::slice::<impl [T]>::to_vec_in::h885d10b1cfcd4103
   22: 0x7bb40 - <unknown>!alloc::slice::<impl [T]>::to_vec::h5083212bb2e14c81
   23: 0x25a43 - <unknown>!liquid_lang::lang_core::storage::cell::typed_cell::TypedCell<T>::new::ha7ebd5c4811cd7f3
   24: 0x138c2 - <unknown>!liquid_lang::lang_core::storage::cell::cached_cell::CachedCell<T>::new::h4093120e1570dec6
   25: 0xfd04 - <unknown>!<liquid_lang::lang_core::storage::value::Value<T> as liquid_lang::lang_core::storage::traits::Bind>::bind_with::hc390e7ecb7ed1422
   26: 0xa054 - <unknown>!<parallelok::parallel_ok::__liquid_private::__liquid_storage::Storage as liquid_lang::lang_core::storage::traits::New>::new::h2cc23a83c1212243
   27: 0xbadb - <unknown>!parallelok::parallel_ok::__liquid_private::_::<impl parallelok::parallel_ok::__liquid_private::__liquid_storage::Storage>::dispatch::h5004208c4c584335
   28: 0x34613 - <unknown>!main
note: run with `WASMTIME_BACKTRACE_DETAILS=1` environment variable to display more information

Is there some way to reset the state of an instance after each execution? Or maybe there is a better way to interrupt the execution elegant?

I found wasmtime_interrupt_handle_interrupt, the wasmtime_interrupt_handle should call from another thread? Can I call it in the host function called by wasm? If I call wasmtime_interrupt_handle will the linear memory be reset?

Wasmtime GitHub notifications bot (Mar 26 2021 at 09:32):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton It seems if I use linear memory in wasm and the function F in wasm exit by call host function to return a trap, the memory allocated by the F is not freed, then the next time calls the F the memory usage of instance will grow. As the memory growing, at some time the trap return out of bounds memory access.I guess either the way stop execution makes troubles, or the wasm I used has bugs in manage linear memory.

call main, error message: wasm trap: out of bounds memory access
wasm backtrace:
    0: 0x8c73c - <unknown>!wee_alloc::FreeCell::try_alloc::hb2660e954f6e5223
    1: 0x8d3c7 - <unknown>!wee_alloc::alloc_first_fit::{{closure}}::hfd5f453a5b3dec0c
    2: 0x8d227 - <unknown>!wee_alloc::walk_free_list::hd831c341105a6b2d
    3: 0x8d596 - <unknown>!wee_alloc::alloc_first_fit::h7f42292292e49180
    4: 0x8d603 - <unknown>!wee_alloc::alloc_with_refill::h3525530d2d10e1ae
    5: 0x8da3f - <unknown>!wee_alloc::WeeAlloc::alloc_impl::{{closure}}::hd235f0224f501596
    6: 0x8d97f - <unknown>!wee_alloc::WeeAlloc::with_free_list_and_policy_for_size::{{closure}}::h1153d640b2b12f57
    7: 0x906ea - <unknown>!wee_alloc::imp_wasm32::Exclusive<T>::with_exclusive_access::hebe42350c45bd1b7
    8: 0x8d8bb - <unknown>!wee_alloc::WeeAlloc::with_free_list_and_policy_for_size::h06f3b976cadcd3c9
    9: 0x8df5e - <unknown>!wee_alloc::WeeAlloc::alloc_impl::hbd0790bc4271633f
   10: 0x8e169 - <unknown>!<wee_alloc::WeeAlloc as core::alloc::global::GlobalAlloc>::alloc::h366b133ed0c2cb3f
   11: 0x8b3c6 - <unknown>!__rg_alloc
   12: 0x47f5b - <unknown>!__rust_alloc
   13: 0x86f0f - <unknown>!alloc::alloc::alloc::hc87f001bc6c9f141
   14: 0x8702d - <unknown>!alloc::alloc::Global::alloc_impl::haa97078f3f34b5da
   15: 0x86e74 - <unknown>!<alloc::alloc::Global as core::alloc::Allocator>::allocate::hfa4575a09cbd1182
   16: 0x83d35 - <unknown>!alloc::raw_vec::RawVec<T,A>::allocate_in::h1570326482613819
   17: 0x85490 - <unknown>!alloc::raw_vec::RawVec<T,A>::with_capacity_in::h5abb55ecde21b81f
   18: 0x80d1c - <unknown>!alloc::vec::Vec<T,A>::with_capacity_in::hfafb52572c534d64
   19: 0x86c97 - <unknown>!<T as alloc::slice::hack::ConvertVec>::to_vec::hc813c591a8fa1bfd
   20: 0x87a10 - <unknown>!alloc::slice::hack::to_vec::hef5ce951d3ea8fbe
   21: 0x7bb8e - <unknown>!alloc::slice::<impl [T]>::to_vec_in::h885d10b1cfcd4103
   22: 0x7bb40 - <unknown>!alloc::slice::<impl [T]>::to_vec::h5083212bb2e14c81
   23: 0x25a43 - <unknown>!liquid_lang::lang_core::storage::cell::typed_cell::TypedCell<T>::new::ha7ebd5c4811cd7f3
   24: 0x138c2 - <unknown>!liquid_lang::lang_core::storage::cell::cached_cell::CachedCell<T>::new::h4093120e1570dec6
   25: 0xfd04 - <unknown>!<liquid_lang::lang_core::storage::value::Value<T> as liquid_lang::lang_core::storage::traits::Bind>::bind_with::hc390e7ecb7ed1422
   26: 0xa054 - <unknown>!<parallelok::parallel_ok::__liquid_private::__liquid_storage::Storage as liquid_lang::lang_core::storage::traits::New>::new::h2cc23a83c1212243
   27: 0xbadb - <unknown>!parallelok::parallel_ok::__liquid_private::_::<impl parallelok::parallel_ok::__liquid_private::__liquid_storage::Storage>::dispatch::h5004208c4c584335
   28: 0x34613 - <unknown>!main
note: run with `WASMTIME_BACKTRACE_DETAILS=1` environment variable to display more information

Is there some way to reset the state of an instance after each execution? Or maybe there is a better way to interrupt the execution elegant?

I found wasmtime_interrupt_handle_interrupt, the wasmtime_interrupt_handle should call from another thread? Can I call it in the host function called by wasm? If I call wasmtime_interrupt_handle will the linear memory be reset?

Wasmtime GitHub notifications bot (Mar 26 2021 at 09:33):

bxq2011hust edited a comment on Issue #2751:

@alexcrichton It seems if I use linear memory in wasm and the function F in wasm exit by call host function to return a trap, the memory allocated by the F is not freed, then the next time calls the F the memory usage of instance will grow. As the memory growing, at some time the trap return out of bounds memory access, and the instance will be failed from then.I guess either the way stop execution makes troubles, or the wasm I used has bugs in manage linear memory.

call main, error message: wasm trap: out of bounds memory access
wasm backtrace:
    0: 0x8c73c - <unknown>!wee_alloc::FreeCell::try_alloc::hb2660e954f6e5223
    1: 0x8d3c7 - <unknown>!wee_alloc::alloc_first_fit::{{closure}}::hfd5f453a5b3dec0c
    2: 0x8d227 - <unknown>!wee_alloc::walk_free_list::hd831c341105a6b2d
    3: 0x8d596 - <unknown>!wee_alloc::alloc_first_fit::h7f42292292e49180
    4: 0x8d603 - <unknown>!wee_alloc::alloc_with_refill::h3525530d2d10e1ae
    5: 0x8da3f - <unknown>!wee_alloc::WeeAlloc::alloc_impl::{{closure}}::hd235f0224f501596
    6: 0x8d97f - <unknown>!wee_alloc::WeeAlloc::with_free_list_and_policy_for_size::{{closure}}::h1153d640b2b12f57
    7: 0x906ea - <unknown>!wee_alloc::imp_wasm32::Exclusive<T>::with_exclusive_access::hebe42350c45bd1b7
    8: 0x8d8bb - <unknown>!wee_alloc::WeeAlloc::with_free_list_and_policy_for_size::h06f3b976cadcd3c9
    9: 0x8df5e - <unknown>!wee_alloc::WeeAlloc::alloc_impl::hbd0790bc4271633f
   10: 0x8e169 - <unknown>!<wee_alloc::WeeAlloc as core::alloc::global::GlobalAlloc>::alloc::h366b133ed0c2cb3f
   11: 0x8b3c6 - <unknown>!__rg_alloc
   12: 0x47f5b - <unknown>!__rust_alloc
   13: 0x86f0f - <unknown>!alloc::alloc::alloc::hc87f001bc6c9f141
   14: 0x8702d - <unknown>!alloc::alloc::Global::alloc_impl::haa97078f3f34b5da
   15: 0x86e74 - <unknown>!<alloc::alloc::Global as core::alloc::Allocator>::allocate::hfa4575a09cbd1182
   16: 0x83d35 - <unknown>!alloc::raw_vec::RawVec<T,A>::allocate_in::h1570326482613819
   17: 0x85490 - <unknown>!alloc::raw_vec::RawVec<T,A>::with_capacity_in::h5abb55ecde21b81f
   18: 0x80d1c - <unknown>!alloc::vec::Vec<T,A>::with_capacity_in::hfafb52572c534d64
   19: 0x86c97 - <unknown>!<T as alloc::slice::hack::ConvertVec>::to_vec::hc813c591a8fa1bfd
   20: 0x87a10 - <unknown>!alloc::slice::hack::to_vec::hef5ce951d3ea8fbe
   21: 0x7bb8e - <unknown>!alloc::slice::<impl [T]>::to_vec_in::h885d10b1cfcd4103
   22: 0x7bb40 - <unknown>!alloc::slice::<impl [T]>::to_vec::h5083212bb2e14c81
   23: 0x25a43 - <unknown>!liquid_lang::lang_core::storage::cell::typed_cell::TypedCell<T>::new::ha7ebd5c4811cd7f3
   24: 0x138c2 - <unknown>!liquid_lang::lang_core::storage::cell::cached_cell::CachedCell<T>::new::h4093120e1570dec6
   25: 0xfd04 - <unknown>!<liquid_lang::lang_core::storage::value::Value<T> as liquid_lang::lang_core::storage::traits::Bind>::bind_with::hc390e7ecb7ed1422
   26: 0xa054 - <unknown>!<parallelok::parallel_ok::__liquid_private::__liquid_storage::Storage as liquid_lang::lang_core::storage::traits::New>::new::h2cc23a83c1212243
   27: 0xbadb - <unknown>!parallelok::parallel_ok::__liquid_private::_::<impl parallelok::parallel_ok::__liquid_private::__liquid_storage::Storage>::dispatch::h5004208c4c584335
   28: 0x34613 - <unknown>!main
note: run with `WASMTIME_BACKTRACE_DETAILS=1` environment variable to display more information

Is there some way to reset the state of an instance after each execution? Or maybe there is a better way to interrupt the execution elegant?

I found wasmtime_interrupt_handle_interrupt, the wasmtime_interrupt_handle should call from another thread? Can I call it in the host function called by wasm? If I call wasmtime_interrupt_handle will the linear memory be reset?

Wasmtime GitHub notifications bot (Mar 26 2021 at 16:11):

alexcrichton commented on Issue #2751:

Oh valgrind may not actually be too useful now that I think about it, wasm intentionally segfaults and raises illegal instructions, that's how we implement traps efficiently. Alas!

Currently there's no way to reset the state of an instance after each execution. For use cases like that we recommend creating new instances instead of reusing existing instances (provides better isolation for each wasm as well).

For interruption the interrupt handle is indeed intended to be invoked from anotehr thread. It can be called at any time. Interruption only affects execution, it doesn't affect linear memory. There's no way to "reset" linear memory since that's not a wasm concept per se.

Wasmtime GitHub notifications bot (Mar 27 2021 at 09:12):

bxq2011hust commented on Issue #2751:

@alexcrichton Ok, get it. Thanks again! :big_smile:

Last updated: Dec 23 2024 at 12:05 UTC