Hooray wrote in Wed Jun 02, 2021 4:54 pm:It would be interesting to share some backtraces, so that we can take a look and try to determine what's going on.
For instance, Richard mentioned that our "autogen" (random buildings) component is interfering badly with lots of OSG threads.
The new sentry system will upload small memory dumps and produces backtraces (using the pdb on Windows nightly builds). The issue is the fact that OSG_NUM_DATABASE_THREADS was turned up may not be immediately visible.
tom_nl wrote in Wed Jun 02, 2021 6:45 pm:I'm using the 2020.4.0 nightly release. It seems to be rock solid with 4 threads and automatic selection - I don't think it's ever crashed! Never tried more threads as then i'd be into multithreading on the cores. I've flown with the Cessna 172 and K21 using this setup
The "OSG_GL_ERROR_CHECKING=OFF" was more to suppress a load of OpenGL warnings/errors in the console that were rather annoying, especially when debugging other things (mainly arduino serial in/out for my panel).
I tried it with the latest Windows nightly and a very slightly older nightly, and OSG_NUM_DATABASE_THREADS=3. I found the C172P reliably crashes spawning at the runway. The test settings: scenery features/layers on, OSM2City buildings, shaders = max, vegetation = very high, Ai traffic = off. It starts fine with 2 threads.
There has been some work towards making the property tree thread safe with locking (experimental, increases the CPu boundness of FG slightly). Maybe it made FG a bit less crashy on some systems when running lots of DB threads?. The default on the next branch seems to be
--prop:bool:/sim/property-locking=true
--prop:bool:/sim/property-locking-timing=false
For the test I set property-locking to off. It also crashed when I tested once or twice with both set to true.
On nightlies, using the latest pdb file at download.flightgear.org, and using the same process as earlier for trying to find the cause of a hang using windbg call stack:
https://pastebin.com/FVWkthetKind regards