Bug report 1024505.
Looks similar to 1019647. Although mine crashes while playing.
Started seeing this when I moved a good chunk of raycasting and pathfinding over to jobs. Altogether around 5k raycasts/pathfind requests per frame, versus a few hundred raycasts per frame before.
So observing this some more it seems like the real culprit might be the new navmesh queries. Even though most stack traces end in the raycast stuff, some crashes don’t produce a stack trace. And I haven’t had a crash yet with the navmesh queries disabled.
Ok well take that back, it just took longer but still crashed with navmesh stuff disabled.
So evidently changing adding/removing objects in the physics world can crash a raycast job. The first reply I got back hinted that they didn’t consider that a bug as changing the physics world is evidently not support while batched raycasts are happening.
Now that would severely cripple the usefulness, because for example it can crash when the particle system makes updates to the physics world in late update which end users have no control over. Colliders we add/remove I can deal with that.
Anyways right now I’ve had to move most raycasting back to the the main thread. I changed my code so colliders are only added/removed when raycast jobs are not running, so now I still get crashes they just all seem to stem from particles updating in PreLateUpdate.
So I was wondering if I can work around this with a custom PlayerLoop, but was hoping to get some advice on the best place to insert entries (and if it sounds like that will even work).
I don’t need a full update cycle but late update just isn’t enough. It looks like if I insert an event under EarlyUpdate to kick off jobs, and them complete them at the end of update, that might work?
So I think that did it although need to give it a bit more time.