Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007912opensim[REGION] Physics Enginespublic2016-05-28 22:212016-06-24 19:40
ReporterBillBlight 
Assigned To 
PrioritynormalSeveritycrashReproducibilityalways
StatusnewResolutionopen 
PlatformOSOS Version
Product Versionmaster (dev code) 
Target VersionFixed in Version 
Summary0007912: ubODE Physics Crash when colliding mesh at high speed.
DescriptionWe have scripted pretty fast fighters for our Trek sim, they fly smooth, until impacting other physical object, and 9 out of 10 times the sim crashes.

No error is reported the sim just "GOES AWAY"

(We have tested this on Ubuntu 16 and are unable to reproduce)

Steps To ReproduceFly same ship same speed and run into each other or mesh object.
Additional Informationwe are loving the ubODE physics engine, and we know it is a work in progress.
TagsNo tags attached.
Git Revision or version numberdev master
Run Mode Grid (1 Region per Sim) , Grid (Multiple Regions per Sim)
Physics EngineOther
Script Engine
Environment.NET / Windows64
Mono VersionOther
ViewerFirestorm and Kokua
Attached Files

- Relationships

-  Notes
(0030388)
BillBlight (developer)
2016-05-29 23:32
edited on: 2016-05-29 23:35

managed to catch the crash, not sure if this is the one it always gives usually it just "goes away". Something to note, at this crash it was a physical object colliding with a non-physical mesh at very low velocity, as I was simply dragging the physical object and bumped into the other mesh.

Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. T
his is often an indication that other memory is corrupt.
   at OdeAPI.d.CollidePtr(IntPtr o1, IntPtr o2, Int32 flags, IntPtr contactgeomarray, Int32 skip)
   at OpenSim.Region.PhysicsModule.ubOde.ODEScene.near(IntPtr space, IntPtr g1, IntPtr g2)
   at OdeAPI.d.SpaceCollide2(IntPtr space1, IntPtr space2, IntPtr data, NearCallback callback)
   at OpenSim.Region.PhysicsModule.ubOde.ODEScene.near(IntPtr space, IntPtr g1, IntPtr g2)
   at OdeAPI.d.SpaceCollide2(IntPtr space1, IntPtr space2, IntPtr data, NearCallback callback)
   at OpenSim.Region.PhysicsModule.ubOde.ODEScene.near(IntPtr space, IntPtr g1, IntPtr g2)
   at OdeAPI.d.SpaceCollide2(IntPtr space1, IntPtr space2, IntPtr data, NearCallback callback)
   at OpenSim.Region.PhysicsModule.ubOde.ODEScene.collision_optimized()
   at OpenSim.Region.PhysicsModule.ubOde.ODEScene.Simulate(Single reqTimeStep)
   at OpenSim.Region.Framework.Scenes.SceneGraph.UpdatePhysics(Double elapsed)
   at OpenSim.Region.Framework.Scenes.Scene.Update(Int32 frames)
   at OpenSim.Region.Framework.Scenes.Scene.Heartbeat()
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallba
ck callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callb
ack, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callb
ack, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

(0030399)
BillBlight (developer)
2016-05-30 22:19

This may be of note ..

IF we change the density of the vehicle to 1.000 from the default 1000 it seems that it does not crash , as often. This seems to mitigate the the problem but it still exists.
(0030741)
UbitUmarov (administrator)
2016-06-24 17:22

this seems to be a crash deep in the unmanaded ode lib, so most time region will just die :(
This is something related to the mesh used for physics, either too large or with some thing that breaks ode collision code :(
I can't tell without it.
As general rule, you should use a simplified mesh for physics, or set the mesh to shape type none and adding a few invisible prims to form a simplified collision body.
(0030742)
BillBlight (developer)
2016-06-24 17:54

We have actually been able to replicate this with a prim, it is not only affecting mesh ..

As far as the the "workaround", having a working physics engine , and good physical vehicles, is useless if you have to use those workarounds.

Don't get me wrong I understand that it is a work in progress, and I am not chewing on you for the problem .. Just hoping that we get a "real" 3d physics engine at some point , and ubode is the closest thing yet.
(0030744)
UbitUmarov (administrator)
2016-06-24 18:10

All physics engines for games or virtual worlds need a simplified representation.
Real 3d simulation is outside the scope of this applications.
See in description you are running in windows, correct?
(0030745)
BillBlight (developer)
2016-06-24 18:12

Yes I understand the need to simplify, but OVERsimplifying should not be needed. And sorry I have a little bit of history playing around in the Unreal engine, so sometimes I forget that we are in a much simpler world ..

Yes running on windows, but I CAN make it crash on linux(ubuntu x64) if I really try hard .. HAHA
(0030746)
BillBlight (developer)
2016-06-24 18:14

If I had to guess it is a timer issue, as we know linux handles those much better and faster than windows does .. To me it looks like the collision timer is running over itself ..
(0030747)
UbitUmarov (administrator)
2016-06-24 18:17

What I said applies also to Unreal if you are using it right :p
If you can give me a test set/conditions that cause that crash, I can try to reproduce it
(0030748)
BillBlight (developer)
2016-06-24 18:17

Is there a way to make ubODE run in a completely separate thread/process? I am not 100% sure but it appears that the the crashes may also be concurrent with those pesky "watchdog" timer timeouts ...
(0030749)
BillBlight (developer)
2016-06-24 18:19

I'll put together some of our test objects, and see if I can get them to you (my script guy is really touchy about his custom vehicle scripts). I have been able to replicate it with "stock" scripts.

It may be a few days, taking a break from the sim for a few days. I will get it to you soon.
(0030750)
BillBlight (developer)
2016-06-24 18:23
edited on: 2016-06-24 18:27

In the meantime simplest way I can think to replicate it, is ..

Take a "stock" physical vehicle script from SL, crank it's speed to the max in a physical prim at least "avatar size" run it into another physical prim of the same size or larger.. (sometimes it does not matter if you collide with a physical or non-physical prim)

Density seems to be a factor, density should be at least 1000 .. If you set density to 1.000 it seems to "almost" stop the issue.

(0030751)
UbitUmarov (administrator)
2016-06-24 18:34

why are you having timeouts? region has other objects and is loaded?
Bullet, ode and ubOde run on the heartbead thread. Only bullet has a option to run on own thread currently.
(0030752)
BillBlight (developer)
2016-06-24 18:37

We don't seem to get any actual timeouts, just that pesky watchdog timer error on the console once in a while .. Sim FPS and Sim Physics pretty much stay pegged at 55ish ..


The sim is fully loaded and we tested it with a single sim, and a var with NOTHING on it but land and two vehicles ... On multiple servers... My server is a 24 core xeon with 128gb of ram .. Speed is not an issue....
(0030753)
UbitUmarov (administrator)
2016-06-24 19:27

I did some testing with a car and a box (with and without hole).
Collided at high speed from different angles with no issues
guess this is going to be a bit hard to debug :(
(0030754)
UbitUmarov (administrator)
2016-06-24 19:32

forgot to mention I also tested different densities with no effect, at least from the log above they should make no difference, since that shows a crash on collision code.
if you can, paste there one of those watchdog timer error..
(0030755)
UbitUmarov (administrator)
2016-06-24 19:33

im assuming you also selected ubMeshmerizer...
(0030756)
BillBlight (developer)
2016-06-24 19:40

Yes using ubMeshmerizer ...

It is so strange, because I can make it do it on ANY of my systems, including a standalone ... BUT then again I have not tested it with the "latest" dev code.

I'll try and get you some of the watchdog timer events .. Not where I can get to the servers right now ..

I tested on 6 different machine configs... <shrug>

I agree that the density should not have an effect, but, it really does seem to ..

I'll get you some more info as soon as I get back to the servers ...

The watchdog error is usually like this one ...

14:45:04 - [WATCHDOG]: Timeout detected for thread "AsyncLSLCmdHandlerThread". ThreadState=Background, WaitSleepJoin. Last tick was 6641ms ago.

- Issue History
Date Modified Username Field Change
2016-05-28 22:21 BillBlight New Issue
2016-05-29 23:32 BillBlight Note Added: 0030388
2016-05-29 23:35 BillBlight Note Edited: 0030388 View Revisions
2016-05-30 22:19 BillBlight Note Added: 0030399
2016-06-24 17:22 UbitUmarov Note Added: 0030741
2016-06-24 17:54 BillBlight Note Added: 0030742
2016-06-24 18:10 UbitUmarov Note Added: 0030744
2016-06-24 18:12 BillBlight Note Added: 0030745
2016-06-24 18:14 BillBlight Note Added: 0030746
2016-06-24 18:17 UbitUmarov Note Added: 0030747
2016-06-24 18:17 BillBlight Note Added: 0030748
2016-06-24 18:19 BillBlight Note Added: 0030749
2016-06-24 18:23 BillBlight Note Added: 0030750
2016-06-24 18:27 BillBlight Note Edited: 0030750 View Revisions
2016-06-24 18:34 UbitUmarov Note Added: 0030751
2016-06-24 18:37 BillBlight Note Added: 0030752
2016-06-24 19:27 UbitUmarov Note Added: 0030753
2016-06-24 19:32 UbitUmarov Note Added: 0030754
2016-06-24 19:33 UbitUmarov Note Added: 0030755
2016-06-24 19:40 BillBlight Note Added: 0030756


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker