You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm sometimes getting a crash when testing VoxelLodTerrain. It's happening randomly, but so far it's been happening when duplicate_rejection is enabled in one of the threaded block managers. I need to investigate more to find the cause. It seems to happen more if you move fast in a very erratic way, back and forth etc.
I suspect this one has been there for a while according to 3465334
Clues:
Assigning an input block in shared input, but the previous value in the vector contains a Ref<T> with uninitialized memory, causing garbage delete. Considering stuff like this is able to run, it could be a vector overrun. I also found that in Godot debug builds, _DEBUG isn't defined on Windows, which disables STL boundary checks...
Inserting an item into the block_indexesHashTable which is used for duplicate rejection. But that hashmap's memory was already freed according to the magic number there
Okay, I think I found it.
duplicate rejection isn't locking the mutex to access block_indexes, and both threads are writing to it.
The text was updated successfully, but these errors were encountered:
I'm sometimes getting a crash when testing
VoxelLodTerrain
. It's happening randomly, but so far it's been happening whenduplicate_rejection
is enabled in one of the threaded block managers. I need to investigate more to find the cause. It seems to happen more if you move fast in a very erratic way, back and forth etc.I suspect this one has been there for a while according to 3465334
Clues:
Assigning an input block in shared input, but the previous value in the vector contains a
Ref<T>
with uninitialized memory, causing garbage delete. Considering stuff like this is able to run, it could be a vector overrun. I also found that in Godot debug builds,_DEBUG
isn't defined on Windows, which disables STL boundary checks...Inserting an item into the
block_indexes
HashTable
which is used for duplicate rejection. But that hashmap's memory was already freed according to the magic number thereOkay, I think I found it.
duplicate rejection isn't locking the mutex to access
block_indexes
, and both threads are writing to it.The text was updated successfully, but these errors were encountered: