Godot version
4.0.beta (166066d)
System information
Windows, MSVC custom builds
Issue description
I keep seeing stacktraces with false positives from custom MSVC builds, of this form:
CrashHandlerException: Program crashed
Engine version: Godot Engine v4.0.beta.custom_build (https://github.com/godotengine/godot/commit/166066d9f74e574b68d9f9d0ba05bf42b8de2131)
Dumping the backtrace. Please include this when reporting the bug on: [godotengine/godot/issues](https://github.com/godotengine/godot/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc)
[0] <couldn't map PC to fn name>
[1] <couldn't map PC to fn name>
[2] embree::TaskScheduler::wait
[3] oidnUnmapBuffer
[4] oidnUnmapBuffer
...
[42] oidnUnmapBuffer
[43] oidnUnmapBuffer
[44] oidnUnmapBuffer
[45] embree::TaskScheduler::wait
[46] embree::TaskScheduler::wait
[47] embree::TaskScheduler::wait
[48] <couldn't map PC to fn name>
[49] <couldn't map PC to fn name>
[50] <couldn't map PC to fn name>
[51] <couldn't map PC to fn name>
[52] embree::TaskScheduler::wait
[53] BaseThreadInitThunk
-- END OF BACKTRACE --
(This one is from #69259 (comment) but there's plenty other examples.)
Such crashes do NOT occur in embree or oidn. Instead, it seems to be more a case of those libraries polluting the global namespace and we wrongly resolve to their symbols.
Would be good to find how to prevent this false positive, it's one thing to have a useless backtrace due to missing debug symbols, but it's worse when it wrongly points to symbols which wouldn't be involved in the crash.
Steps to reproduce
- Compile Godot with MSVC, without debug symbols
- Make it crash
(Didn't test exact steps to reproduce as I'm not on Windows currently.)
Minimal reproduction project
n/a
Godot version
4.0.beta (166066d)
System information
Windows, MSVC custom builds
Issue description
I keep seeing stacktraces with false positives from custom MSVC builds, of this form:
(This one is from #69259 (comment) but there's plenty other examples.)
Such crashes do NOT occur in embree or oidn. Instead, it seems to be more a case of those libraries polluting the global namespace and we wrongly resolve to their symbols.
Would be good to find how to prevent this false positive, it's one thing to have a useless backtrace due to missing debug symbols, but it's worse when it wrongly points to symbols which wouldn't be involved in the crash.
Steps to reproduce
(Didn't test exact steps to reproduce as I'm not on Windows currently.)
Minimal reproduction project
n/a