Is there any support (or planned support) for memory access validation tools such as Valgrind (memcheck), AddressSanitizer, or Dr Memory, with the native allocators used by Jobs and ECS?
#Memory access validation with jobs & ecs
dapper obsidian
tame herald
No; our safety strategy instead focuses on bounds checking (which can be compiled out), leak detection, and concurrency safety with the jobs debugger. The tools you mentioned are more intended for environments like C/C++, where code necessarily is constantly manipulating unsafe pointers, and those tools can help find some of the mistakes in that usage. Broadly, I would say we've seen these strategies be fairly successful for developers (and for ourselves internally, where applicable); we see relatively few issues with random crashes and leaks as you might expect in an engine based on everybody writing C++.
dapper obsidian
i see, that's unfortunate
in my current project i'm seeing a number of disparate sigsegv crashes in the wild (via live crash reporting), typically pretty deep in ecs internals via SystemAPI.Query, .GetSingleton, etc., but haven't been able to reproduce any of them locally
in past c++ game projects what i'd usually do in a situation like this is hand out asan-enabled builds to internal testers and would quickly get some results
(since the crashes don't appear to have any discernible pattern my main suspect is memory corruption somewhere)
but i recognize it's a non-trivial ask and would ultimately be a quite niche feature to have
drowsy inlet