13-05-2021, 08:38 AM
(This post was last modified: 13-05-2021, 08:42 AM by josemendez.)
(13-05-2021, 08:19 AM)Hatchling Wrote: While I still haven't reproduced the exact same results in the repro project as I have in the main project, you may still be able to track it down.
One key thing I noticed in the main project while debugging is, during the second play session, the solver and updater from the previous play session (which were marked with DontDestroyOnLoad) were hitting breakpoints, indicating their activity. If you can detect this in the demo project (even though it doesn't always cause problems), you'll probably be very close to the root cause.
DontDestroyOnLoad is definitely a good lead. If you have trouble, I can try doing the opposite approach to reproducing the bug - instead of building up to the situation I think caused the bug in the repro project, I can remove stuff from the main project until it stops. Hopefully I can remove almost everything and still have the exact same symptoms occur.
My approach is usually getting the bad stuff ™ to happen. Then step trough the code, reason about why is happening and write a unit test that triggers it. Once I understand it, think how to fix it without breaking anything else. Then run the unit tests and verify that it no longer happens. I'll get to it later this morning, depending on how resilient this one is I think I can have a workaround before the weekend. Thanks for the tips!
(13-05-2021, 08:19 AM)Hatchling Wrote: It might also be a good idea to do something about the same solver being added multiple times to one or more updaters. It REALLY seems to hate this. Burst will puke all over the console, and Oni will outright crash Unity.
The behavior in this case is basically undefined, as it's running the same jobs twice in parallel. Might work fine, might cause a race condition and crash. This is warned about in the manual:
http://obi.virtualmethodstudio.com/tutor...aters.html
Quote:There can be multiple updaters in your scene, however you must avoid having the same solver referenced by multiple updaters as this will update that solver more than once per frame, leading to unpredictable results. Also keep in mind that a solver that is not referenced by any updater will not have its simulation updated.
I agree that I should probably check for this in-editor and place a warning in the updater or just refuse to run the simulation if the user adds the same solver twice, though. Won't catch the case where different updaters update the same solver, but at least it will warn about the single updater case. Will do in the next update.