-
-
Notifications
You must be signed in to change notification settings - Fork 404
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fatal error without crash dump when multiprocessing #355
Comments
First thing that springs to my mind are some mentions about collisions of shared resources when booting up multiple instances. One decent workaround was to add random amount of sleep before creating DoomGame instances. I have not had such issues in the past. Trying your code on Windows 10 and Ubuntu 16.04 I am not getting same errors with threads from 8 to 36 and with different number of maps. I assume you are using some other scenario file than freedoom2.wad, given that it does not have 64 maps to begin with? Could some of the levels be corrupted? |
In the posted example script, I'm using freedom2.wad. The map is set to I tried adding a random amount of sleep (up to 5 seconds) before creating DoomGame instances, but that did not help.. still getting the error. I'm using Ubuntu 16.04 with Python 3.7. |
@Miffyli I find the errors more frequently with threads = 4, even compared to the higher numbers. Could you try that with a larger timeout and maps? Usually the errors show up near the end. You may also need to run the script a few times to get it. |
Now I got some "fatal errors" at the end with I have no idea what could cause them, but they seem to happen on destruction of DoomGame objects (when the process ends), judging by how all indexes seem to be covered as expected. Additionally, semi-offtopic: I take back what I said about 36 threads: It does crash at times with different error. The issue seems to be with importing vizdoom, rather than launching it. I tried creating separate Processes with random delays in between, and now I can happily launch 40 workers (note: indexing may not be correct): if __name__ == "__main__":
step = int(np.ceil(flags.n_maps / flags.threads))
for i in range(flags.threads):
sleep(random.random()*0.1)
worker = Process(target=generate,
args = (list(range(i*step, min(i*step + step, flags.n_maps + 1))),))
worker.start() |
I tried using a different copy per thread of the .ini file, config file, and WAD file, but that did not help (which is in line with your assessment that the problem might be with importing). Also, calling |
Instead of using the random delay, the following code waits until one process is done importing vizdoom, creating a DoomGame instance and initializing it before the next process is created: step = int(np.ceil(flags.n_maps / flags.threads))
for i in range(1, flags.n_maps + 1, step):
parent_conn, child_conn = Pipe()
worker = Process(target=generate,
args=(range(i, min(i + step, flags.n_maps + 1)), child_conn))
worker.start()
parent_conn.recv() (there is a This still results in the fatal error messages. The only workaround that has worked all the time so far for me is closing and initing the game after a fixed number (<=15 for freedom2.wad, <=14 for a custom WAD I'm using) of map changes. |
Hello @ankitkv, |
It looks like that fixes it! |
Keeping this issue open until @mwydmuch decides to close it. Especially since the exact cause was still unknown. |
Script to reproduce and output are as follows.
Here is an example Python3 script (running Python3.7):
The config file
defaults.cfg
is:The output of the script with default arguments ends with:
No crash file is created, and there is no indication as to what is going wrong. This does not happen when multiprocessing is not used. If you're unable to reproduce, try increasing the timeout, changing the number of threads, and increasing the number of maps, in that order.
Any immediate idea what the problem is?
The text was updated successfully, but these errors were encountered: