Search the Community

I have the following situation: In my application there are 2 important threads (there are more, but only 2 are involved in the application): One thread that periodically calls WorldNode::getIntersection (well, it calls WorldInterface::getIntersection) in order to perform calculations based on the location of the player and another thread that does everything else (rendering, drawing graphics, handling user input, etc). The application crashes at random (sometimes after 5 minutes, sometimes after an hour), but a core dump always reveals that the crash was caused by a SIGABRT raised from WorldNode::getIntersection. Since this happens at random, I figure its thread-related (i.e.: Thread1 is calling a getIntersection, just as Thread2 is updating something). Can someone verify / refute this. Alternate theories on why this happens are welcome. I'm using Unigine V2.3.

Hi, I'm investigating how to get physics deterministic. Of course I started out at setting physics.setStable(1) and using a fixed timestep (we modified the clock so we control each phyics time step.) Also, I set the budget to 1e6 so each step is not terminated before the budget runs out.. Also this reported bug has to be fixed before any deterministic results can be achieved. Starting two instances of the same sample (for example shapes/sphere_01) yield different outcomes which can be easily checked by visual inspection of the endposition of the individual spheres between the two application instances. I dug into the code and started logging the individual position of each sphere for each physics step into a file. Comparing the two files (from two application instances) show that the initial state is equal, but they diverge at a random moment during execution. Delving deeper, I also started writing to the file when each island was processed by which thread. I noticed that just before the sphere positions between the two instances diverge, they execute islands in a different order. So, it seems a multithreading issue. I ran the samples with physics single threaded many times, and then the results are always equal, so it is definitely a multithreading issue. Delving deeper into the code I did not find any race condition, or any interaction between the islands which might cause threading related read/write issues. My last suspicion is in the cpu context switch. Maybe the FPU/SSE registers are not saved on context switching causing the calculations to diverge? What is your opinion on this hypothesis? Best regards, Jorrit