[Bug Report] Getting "Environment [some ID] doesn't exist" when using custom async vector env. #222
Comments
|
I have copied and pasted your code and don't get an issue. |
|
Ooh, this one is spicy, I can actually reproduce it locally, and I realized that I lowkey had the same issue some months back, but didn't think about its wider implications. Note: I'm not an expert on python multiprocessing, so details might be off, but I'm pretty sure this is the general idea of what's happening. To potentially make things even spicier (and why @pseudo-rnd-thoughts couldn't replicate it) - this might depend on the operating system. I'm also getting the error on MacOS, but a quick test on colab seems to pass without a problem. This might be related to the start methods in multiprocessing. It seems that MacOS (and Windows) uses As for the solution, the vector API is undergoing a complete rewrite at the moment, so we'll definitely have to think about what to do. When I came across this issue in the past, I used a super ugly workaround of doing the imports/registration inside on the subprocesses. Maybe it would be viable to restrict async envs to a specific start method that behaves well? We'll have to think about it. At the very least the new API should allow directly choosing the start method. The temporary workaround could be monkey-patching the tl;dr I blame the GIL (quite possibly incorrectly, but shh) |
|
I can't work on the implementation right now, but I wanted to write down my thoughts on how this can be solved. After some reading, turns out that global variables are properly inherited for In principle we could restrict it to using The best "robust" option is probably to pass the entire env registry as an argument to the async environment worker, and then use those specifications instead of directly using If it does turn out to be a problem, we can also consider using shared memory to distribute a single copy of the registry between different workers. This should hopefully be straight-forward, as long as multiprocessing doesn't do anything weird. |
|
Could we look to include this in v0.28 experimental vector implementation? I think the idea of a shared memory object would be the best way of doing this. |
|
@sven1977 or @RedTachyon I'm looking to include a fix for this in the next releases however I'm still unable to replicate the issue on my Macbook. def test_async_with_dynamically_registered_env():
gym.register("TestEnv-v0", CartPoleEnv)
gym.make_vec("TestEnv-v0", vectorization_mode="async")
del gym.registry["TestEnv-v0"] |
|
I can replicate the issue on Windows 11 with the following error.
EDIT: |
|
Hi, we haven't been able to replicate the issue for our CI in order to solve this issue. |
|
The code example provided in the first post of the issue does replicate the issue for my case. |
|
Strangely, my laptop now raises the error using the original code (which it did not as I commented). |
|
Closing in favor of PR #810 |
Describe the bug
When running the below script (custom gymnasium.Env registered with an ID, then async-vectorized), I'm getting a
gymnasium.error.NameNotFound: Environment my_env doesn't exist.error.The full stacktrace is:
Code example
import gymnasium as gym import numpy as np class MyEnv(gym.Env): def __init__(self): self.action_space = gym.spaces.Discrete(2) self.observation_space = gym.spaces.Box(0, 100, (1,), dtype=np.float32) self.i = 0 def reset(self, *, seed=None, options=None): self.i = 0 return self._get_obs(), {} def step(self, action): self.i += 1 return self._get_obs(), 1.0, False, self.i >= 5, {} def _get_obs(self): return np.array([self.i], dtype=np.float32) if __name__ == "__main__": gym.register("my_env", MyEnv) env = gym.vector.make("my_env", num_envs=2, asynchronous=True)System info
Mac OS (laptop)
python 3.8.13
gymnasium 0.26.3
gym 0.26.2 (not needed, but installed for Atari)
Additional context
No response
Checklist
The text was updated successfully, but these errors were encountered: