#2000 closed defect (fixed)
OOS in a multiplayer game against Aegis
Reported by: | scythetwirler | Owned by: | Yves |
---|---|---|---|
Priority: | Release Blocker | Milestone: | Alpha 15 |
Component: | Core engine | Keywords: | |
Cc: | Patch: |
Description
I got another OOS error while playing on Oasis 9 against Aegis with a friend.
It seems there was a discrepancy concerning whether one of the AI's units was walking or idle between the client and the host.
This may be a duplicate of #1881, but here are the logs just the case.
Attachments (8)
Change History (18)
by , 11 years ago
Attachment: | difference.txt.tar.7z added |
---|
by , 11 years ago
Attachment: | Em_oos_dump.txt.tar.7z added |
---|
by , 11 years ago
Attachment: | scythetwirler_oos_dump.txt.tar.7z added |
---|
by , 11 years ago
Attachment: | Em_scythetwirler.diff added |
---|
comment:1 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 by , 11 years ago
Milestone: | Alpha 14 → Alpha 15 |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
comment:3 by , 11 years ago
Still occurs with A14 release and using our own Math.sqrt
implementation doesn't solve it. Happens basically every game between my friend and I.
comment:4 by , 10 years ago
Owner: | set to |
---|---|
Status: | reopened → new |
I've found a way to reproduce such an OOS problem with Aegis and I'm now trying to find the issue. I should have more information or a solution this weekend.
comment:5 by , 10 years ago
Status: | new → assigned |
---|
comment:6 by , 10 years ago
It's a Spidermonkey JIT problem. I can reliably get different results on different machines and sometimes also on the same machine.
This patch works around the problem by adding "try {} finally {}" which is not supported by the v1.8.5 JIT compiler and prevents it from JIT compiling the functions/loops (thanks to the guys on the #jsapi channel for this tip!). With this patch I was able to run the replay twice on my development client and my VM without any differences. Before the patch I ran it countless times and only once got the same result by chance.
I'm not sure if the first "try {} finally {}" block is needed, I will have to test that a bit more tomorrow and will also add comments for the final patch. The clean solution for this is upgrading Spidermonkey, but I'd say this workaoround is reasonable for the moment.
by , 10 years ago
Attachment: | disable_jit_as_OOS_workaround_v1.0.diff added |
---|
work around the OOS problem by disabling JIT compiling for a problematic function/loop
by , 10 years ago
Attachment: | commands.txt added |
---|
the commands.txt I used to reliably reproduce the problem
comment:7 by , 10 years ago
Can you give some details on how you located the source of the OOS? AI state isn't serialized so it would be interesting to know how it can be narrowed down. It should probably go on Debugging.
comment:8 by , 10 years ago
I've updated the Debugging wiki article. Basically I printed all the commands from the AI players as described. This revealed that different move commands are coming from the AI when it starts an attack. Then I added additional debug output to all the places in attack_plan.js where the AI sends move commands and slowly got closer to the source of the problem by comparing a lot of output logs from replays with filediffs.
comment:10 by , 10 years ago
Nice work, my friend and I will try with A15 once it's released, since we had OOS every game before :)
Resolving this as fixed in A14 :) If the OOS can be reproduced with A14 or later, please reopen and attach relevant logs.