Crash on exit with a StyleBox configured in Godot Inspector or referenced in C# scripts #86229
Comments
|
I have done further analysis for the Godot specialist that will look at this issue. Everything is pointing to the fact that this is a native exception in unmanaged code. The Access violation occurred in the topmost entry 00 godot_windows_template_debug_x86_64_mono!ZN6embree13TaskScheduler12startThreadsEv+0x2d7c49f. I disassembled the code around the faulting instruction. This might provide some insights into what the code was trying to do when it crashed. This was the register to which rcx was pointing: Memory inspection confirms use-after-free issue 0:000> dq rcx No managed exception is present on the thread, which aligns with the native nature of the crash. From this analysis, it seems the issue is a bug in the native code of the Godot engine or a related library, possibly Embree. This is caused due to improper memory management, as I have evidenced above, where we can clearly see memory being accessed after it has been freed. To further investigate, the Godot team might consider looking into the Godot engine's use of Embree, especially around thread management. This is most definitely a crash, please add that label to this issue |
|
Am I to understand correctly that I need to create new export templates with C++ debug logging enabled and replicate the error and give you the WinDbg errors hopefully with more information such as which variables/C++ lines were part of the faulty operation? |
Yeah, since there's no debugging information, the exact file/line where that issue is happening is unknown. The reason it even says that it's ocurring on godot/thirdparty/embree/common/tasking/taskschedulerinternal.cpp Lines 145 to 149 in 2d0ee20 |
YuriSizov
added
topic:core
needs testing
crash
topic:export
and removed
topic:dotnet
labels
|
I understand. I have been trying to generate the export templates for Godot 4.2.1 with C++ symbols (.PDB file) following the guide you provided, sadly with no success. It exports the following files
scons p=windows target=editor module_mono_enabled=yes The .PDB file containing the C++ symbols is missing so the .exe is useless. There don't seem to be any parameters I can set to force it to give me the .PDB and corresponding .EXE i need. I encounter no errors when running the commands I stated. Is there a way you could provide the templates with the corresponding .PDB file, then I could immediately explore additional details for the error. |
|
To build Godot with debug symbols you need to pass |
Thanks, that worked, I am going to try and use it with WinDbg and see what I can uncover with the extra symbols for C++ |
|
Exception CallStack: dissamble command around faulting stack: Registrar state: Exception analysis report: Failed to request MethodData, not in JIT code range KEY_VALUES_STRING: 1 PROCESSES_ANALYSIS: 1 SERVICE_ANALYSIS: 1 STACKHASH_ANALYSIS: 1 ADDITIONAL_XML: 1 OS_BUILD_LAYERS: 1 TIMELINE_ANALYSIS: 1 Timeline: !analyze.Start Timeline: Dump.Current Timeline: Process.Start Timeline: OS.Boot DUMP_CLASS: 2 DUMP_QUALIFIER: 0 MODLIST_WITH_TSCHKSUM_HASH: 6497984623e0415487c795b58f65a93dd03636b4 MODLIST_SHA1_HASH: cdf2c1e2258931701fb07864f4430eb3058bc64c NTGLOBALFLAG: 70 PROCESS_BAM_CURRENT_THROTTLED: 0 PROCESS_BAM_PREVIOUS_THROTTLED: 0 APPLICATION_VERIFIER_FLAGS: 0 PRODUCT_TYPE: 1 SUITE_MASK: 272 DUMP_TYPE: fe FAULTING_IP: EXCEPTION_RECORD: (.exr -1) FAULTING_THREAD: 000016c4 DEFAULT_BUCKET_ID: INVALID_POINTER_READ PROCESS_NAME: godot.windows.template_debug.x86_64.mono.exe FOLLOWUP_IP: READ_ADDRESS: ffffffffffffffff ERROR_CODE: (NTSTATUS) 0xc0000005 - De instructie op 0x%p verwijst naar geheugen op 0x%p. Het geheugen kan niet worden %s. EXCEPTION_CODE_STR: c0000005 EXCEPTION_PARAMETER1: 0000000000000000 EXCEPTION_PARAMETER2: ffffffffffffffff WATSON_BKT_PROCSTAMP: 65804e7e WATSON_BKT_PROCVER: 1.0.0.0 PROCESS_VER_PRODUCT: WATSON_BKT_MODULE: godot.windows.template_debug.x86_64.mono.exe WATSON_BKT_MODSTAMP: 65804e7e WATSON_BKT_MODOFFSET: 2f40986 WATSON_BKT_MODVER: 1.0.0.0 MODULE_VER_PRODUCT: BUILD_VERSION_STRING: 19041.1.amd64fre.vb_release.191206-1406 ANALYSIS_SESSION_HOST: DESKTOP-OG38IEJ ANALYSIS_SESSION_TIME: 12-18-2023 15:07:49.0545 ANALYSIS_VERSION: 10.0.25921.1001 amd64fre MANAGED_CODE: 1 MANAGED_ENGINE_MODULE: coreclr MANAGED_ANALYSIS_PROVIDER: SOS MANAGED_THREAD_ID: 16c4 THREAD_ATTRIBUTES: [ GLOBAL ] [ THREAD ] 0 Id: 55c.16c4 -1 Id: 55c.ffffffff -1 Id: 55c.ffffffff PRIMARY_PROBLEM_CLASS: APPLICATION_FAULT PROBLEM_CLASSES: LAST_CONTROL_TRANSFER: from 00007ff7d9bcde7e to 00007ff7dc600986 STACK_TEXT: STACK_COMMAND: ~0s ; .cxr ; kb FAULT_INSTR_CODE: 48018b48 FAULTING_SOURCE_LINE: D:\a_work\1\s\src\vctools\crt\vcruntime\src\eh\rtti.cpp FAULTING_SOURCE_FILE: D:\a_work\1\s\src\vctools\crt\vcruntime\src\eh\rtti.cpp FAULTING_SOURCE_LINE_NUMBER: 223 FAULTING_SOURCE_CODE: SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: godot_windows_template_debug_x86_64_mono!__RTDynamicCast+46 FOLLOWUP_NAME: MachineOwner MODULE_NAME: godot_windows_template_debug_x86_64_mono IMAGE_NAME: godot.windows.template_debug.x86_64.mono.exe DEBUG_FLR_IMAGE_TIMESTAMP: 65804e7e FAILURE_BUCKET_ID: INVALID_POINTER_READ_c0000005_godot.windows.template_debug.x86_64.mono.exe!__RTDynamicCast BUCKET_ID: APPLICATION_FAULT_INVALID_POINTER_READ_godot_windows_template_debug_x86_64_mono!__RTDynamicCast+46 FAILURE_EXCEPTION_CODE: c0000005 FAILURE_IMAGE_NAME: godot.windows.template_debug.x86_64.mono.exe BUCKET_ID_IMAGE_STR: godot.windows.template_debug.x86_64.mono.exe FAILURE_MODULE_NAME: godot_windows_template_debug_x86_64_mono BUCKET_ID_MODULE_STR: godot_windows_template_debug_x86_64_mono FAILURE_FUNCTION_NAME: __RTDynamicCast BUCKET_ID_FUNCTION_STR: __RTDynamicCast BUCKET_ID_OFFSET: 46 BUCKET_ID_MODTIMEDATESTAMP: 65804e7e BUCKET_ID_MODCHECKSUM: 0 BUCKET_ID_MODVER_STR: 1.0.0.0 BUCKET_ID_PREFIX_STR: APPLICATION_FAULT_INVALID_POINTER_READ_ FAILURE_PROBLEM_CLASS: APPLICATION_FAULT FAILURE_SYMBOL_NAME: godot.windows.template_debug.x86_64.mono.exe!__RTDynamicCast OS_VERSION: 10.0.19041.1 OS_MAJOR: 10 OS_MINOR: 0 OS_BUILD: 19041 OS_REVISION: 1 BUILDDATESTAMP_STR: 191206-1406 OSBUILD_TIMESTAMP: 2019-12-06T14:06:00Z BUILDLAB_STR: vb_release OS_BUILD_STRING: 19041.1.amd64fre.vb_release.191206-1406 BUILDFLAVOR_STR: Checked TARGET_TIME: 2023-12-18T14:07:53.000Z OSSERVICEPACK: 0 OSPLATFORM_TYPE: x64 OSNAME: Windows 10 OSEDITION: Windows 10 WinNt SingleUserTS SYSINFO: FA_ADHOC: IMAGE_VERSION: 1.0.0.0 ANALYSIS_SESSION_ELAPSED_TIME: 116f ANALYSIS_SOURCE: UM FAILURE_ID_HASH_STRING: um:invalid_pointer_read_c0000005_godot.windows.template_debug.x86_64.mono.exe!__rtdynamiccast FAILURE_ID_HASH: {d8196158-cea0-ee0f-f03f-920a1415fe09} Followup: MachineOwner |
|
Do you have a custom stylebox scripted in C#? Edit: I took a liberty to collapse your logs to make this discussion a bit more readable. |
YuriSizov
changed the title
|
The only C# code doing anything with a stylebox is the following code: I also use StyleBoxTexture and StyleBoxFlat on panels in the Godot Editor, I assign that in the inspector. |
YuriSizov
changed the title
YuriSizov
changed the title
|
Okay, so the C# script holds a reference to some styleboxes and that's what causes the crash on exit. We destroy the theme and all its contents before the scripts are finalized, it seems. Seems like it should be possible to create an MRP right now, if you could? |
|
I have created a MRP and the exact same issue happens, your suggestion seems to be the root cause of the issue.. Steps to reproduce:
It must be a faillure in my understanding. The scene in my game that sets that stylebox is destroyed and with that I believe the reference should die as well. I do not set this reference static or in a singleton. So I am surprised it holds on to that, again I must be misunderstanding something. Thanks for your assistance. |
|
I have removed the function from my game. But I still get this error. Now I do NOT have any more C# stylebox references. Can you look into what else is happening. These are the logs (290c.5688): Access violation - code c0000005 (first chance) Stack error registrar state unassembled code around error Analysis report Failed to request MethodData, not in JIT code range KEY_VALUES_STRING: 1 PROCESSES_ANALYSIS: 1 SERVICE_ANALYSIS: 1 STACKHASH_ANALYSIS: 1 ADDITIONAL_XML: 1 OS_BUILD_LAYERS: 1 TIMELINE_ANALYSIS: 1 Timeline: !analyze.Start Timeline: Dump.Current Timeline: Process.Start Timeline: OS.Boot DUMP_CLASS: 2 DUMP_QUALIFIER: 0 MODLIST_WITH_TSCHKSUM_HASH: 28b8f4c061c9141da93652665af98fa416650ef9 MODLIST_SHA1_HASH: 066d6a20f66f61c4c576f35e8331b06b36c225dd NTGLOBALFLAG: 70 PROCESS_BAM_CURRENT_THROTTLED: 0 PROCESS_BAM_PREVIOUS_THROTTLED: 0 APPLICATION_VERIFIER_FLAGS: 0 PRODUCT_TYPE: 1 SUITE_MASK: 272 DUMP_TYPE: fe FAULTING_IP: EXCEPTION_RECORD: (.exr -1) FAULTING_THREAD: 00005688 DEFAULT_BUCKET_ID: INVALID_POINTER_READ PROCESS_NAME: godot.windows.template_debug.x86_64.mono.exe FOLLOWUP_IP: READ_ADDRESS: ffffffffffffffff ERROR_CODE: (NTSTATUS) 0xc0000005 - De instructie op 0x%p verwijst naar geheugen op 0x%p. Het geheugen kan niet worden %s. EXCEPTION_CODE_STR: c0000005 EXCEPTION_PARAMETER1: 0000000000000000 EXCEPTION_PARAMETER2: ffffffffffffffff WATSON_BKT_PROCSTAMP: 65804e7e WATSON_BKT_PROCVER: 1.0.0.0 PROCESS_VER_PRODUCT: Seal The Rift WATSON_BKT_MODULE: godot.windows.template_debug.x86_64.mono.exe WATSON_BKT_MODSTAMP: 65804e7e WATSON_BKT_MODOFFSET: 2f40986 WATSON_BKT_MODVER: 1.0.0.0 MODULE_VER_PRODUCT: Seal The Rift BUILD_VERSION_STRING: 19041.1.amd64fre.vb_release.191206-1406 ANALYSIS_SESSION_HOST: DESKTOP-OG38IEJ ANALYSIS_SESSION_TIME: 12-18-2023 16:31:39.0447 ANALYSIS_VERSION: 10.0.25921.1001 amd64fre MANAGED_CODE: 1 MANAGED_ENGINE_MODULE: coreclr MANAGED_ANALYSIS_PROVIDER: SOS MANAGED_THREAD_ID: 5688 THREAD_ATTRIBUTES: [ GLOBAL ] [ THREAD ] 0 Id: 290c.5688 -1 Id: 290c.ffffffff -1 Id: 290c.ffffffff PRIMARY_PROBLEM_CLASS: APPLICATION_FAULT PROBLEM_CLASSES: LAST_CONTROL_TRANSFER: from 00007ff6a11dde7e to 00007ff6a3c10986 STACK_TEXT: STACK_COMMAND: ~0s ; .cxr ; kb FAULT_INSTR_CODE: 48018b48 FAULTING_SOURCE_LINE: D:\a_work\1\s\src\vctools\crt\vcruntime\src\eh\rtti.cpp FAULTING_SOURCE_FILE: D:\a_work\1\s\src\vctools\crt\vcruntime\src\eh\rtti.cpp FAULTING_SOURCE_LINE_NUMBER: 223 FAULTING_SOURCE_CODE: SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: godot_windows_template_debug_x86_64_mono!__RTDynamicCast+46 FOLLOWUP_NAME: MachineOwner MODULE_NAME: godot_windows_template_debug_x86_64_mono IMAGE_NAME: godot.windows.template_debug.x86_64.mono.exe DEBUG_FLR_IMAGE_TIMESTAMP: 65804e7e FAILURE_BUCKET_ID: INVALID_POINTER_READ_c0000005_godot.windows.template_debug.x86_64.mono.exe!__RTDynamicCast BUCKET_ID: APPLICATION_FAULT_INVALID_POINTER_READ_godot_windows_template_debug_x86_64_mono!__RTDynamicCast+46 FAILURE_EXCEPTION_CODE: c0000005 FAILURE_IMAGE_NAME: godot.windows.template_debug.x86_64.mono.exe BUCKET_ID_IMAGE_STR: godot.windows.template_debug.x86_64.mono.exe FAILURE_MODULE_NAME: godot_windows_template_debug_x86_64_mono BUCKET_ID_MODULE_STR: godot_windows_template_debug_x86_64_mono FAILURE_FUNCTION_NAME: __RTDynamicCast BUCKET_ID_FUNCTION_STR: __RTDynamicCast BUCKET_ID_OFFSET: 46 BUCKET_ID_MODTIMEDATESTAMP: 65804e7e BUCKET_ID_MODCHECKSUM: 0 BUCKET_ID_MODVER_STR: 1.0.0.0 BUCKET_ID_PREFIX_STR: APPLICATION_FAULT_INVALID_POINTER_READ_ FAILURE_PROBLEM_CLASS: APPLICATION_FAULT FAILURE_SYMBOL_NAME: godot.windows.template_debug.x86_64.mono.exe!__RTDynamicCast OS_VERSION: 10.0.19041.1 OS_MAJOR: 10 OS_MINOR: 0 OS_BUILD: 19041 OS_REVISION: 1 BUILDDATESTAMP_STR: 191206-1406 OSBUILD_TIMESTAMP: 2019-12-06T14:06:00Z BUILDLAB_STR: vb_release OS_BUILD_STRING: 19041.1.amd64fre.vb_release.191206-1406 BUILDFLAVOR_STR: Checked TARGET_TIME: 2023-12-18T15:31:43.000Z OSSERVICEPACK: 0 OSPLATFORM_TYPE: x64 OSNAME: Windows 10 OSEDITION: Windows 10 WinNt SingleUserTS SYSINFO: FA_ADHOC: IMAGE_VERSION: 1.0.0.0 ANALYSIS_SESSION_ELAPSED_TIME: 1159 ANALYSIS_SOURCE: UM FAILURE_ID_HASH_STRING: um:invalid_pointer_read_c0000005_godot.windows.template_debug.x86_64.mono.exe!__rtdynamiccast FAILURE_ID_HASH: {d8196158-cea0-ee0f-f03f-920a1415fe09} Followup: MachineOwner |
It's still the same stack trace, so it's still related to C# scripts and styleboxes. I'll check the MRP and let you know what can be done. |
|
Thanks i'll await your results. The only other styleboxes I have are set in the inspector, like so:
|
|
Update Since removing all references in C# to styleboxes did not resolve my issue, I have taken the time to remove all styleboxes that I set in the inspector everywhere in my project. This has resolved the memory access violation. So I would suggest altering the title of this issue to something like: Crash on exit with Stylebox reference in Godot inspector AND/OR reference in C# scripts. Because it happens with either or. Hope this helps! |
|
This is your own issue, you can edit the title yourself ;) |
Benardus
changed the title
|
I have encountered this issue as well. I was able to work around the issue by either doing all stylebox-related work in GDScript, or by calling |
|
Yes I agree, it has to be managed very carefully via code, be it GDscript or C#. The problem is twofold:
Solutions: |
|
I see this issue is assigned to Yuri but I believe he is not part of the Godot Team anymore? Who will be actively picking up this ticket? |
|
After dedicating significant time and effort to this issue over the past three months, it has become clear that this issue seemingly isn't a priority at this time. While I understand the challenges and constraints that the Godot team has, I've decided to close this ticket to effectively focus my time on our commercial project. I would like my challenges and time constraints to be equally respected. I understand that Godot 3 would be more stable for a commercial project, but it wasn't viable for us and it doesn't change how this has been handled. I hope that, in the future, there can be more communication about intent and priority, especially for those of us relying on this engine for commercial projects. |
|
This is still an issue that needs to be solved, so unless it's no longer reproducible, it shouldn't be closed. The need of fixing engine issues isn't scoped only to the original reporter / your project, other users might have the same issue and did not report it, or are waiting for this issue to be solved. As for priorities, we do our best with very limited resources. It will be fixed eventually. If you absolutely need it fixed today, you can look to hire a consultant that would be able to fix it for you (and ideally contribute the fix back upstream via a PR). |
|
I tested the MRP from #86229 (comment) and was able to reproduce the crash on Linux (Fedora 39), albeit with difficulty. It took me around 20 attempts to get it to crash following the steps to reproduce. I confirmed the crash both with 4.2.1.stable.mono and a custom editor build from the Stacktrace: Which is quite similar to the WinDbg one on #86229 (comment) It's not clear to me whether it's ThemeDB's destructor doing something wrong, or CSharpLanguage's hold on instances. CC @godotengine/dotnet |
Tested versions
System information
Godot v4.2.1.stable.mono - Windows 10.0.19044 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2060 (NVIDIA; 31.0.15.3623) - AMD Ryzen 5 2600X Six-Core Processor (12 Threads)
Issue description
I export the game with Godot 4.2.1 (it happens with all 4.x versions) and when I start the game it runs fine. If I immediately quit the game GetTree().Quit() has no issues. When I play the game for a little while (5 mins or so). I always get an memory access violation.
There are no errors when I launch the game via CMD with -verbose. I only get this, which is clean.
However Windows Event Viewer will log an error in the application logs:
I understand that this has to do with a memory access violation. I am using C# and I am not manually setting pointers or handling threads. I have the most detailed Exception Analysis from WinDBG but it points to Embree, a high-performance ray tracing kernel library, which is part of the call stack (STR_exe!ZN6embree13TaskScheduler12startThreadsEv). Below I will share the entire analysis:
Steps to reproduce
See the MRP with instructions
Minimal reproduction project (MRP)
Has been provided in a later comment in this thread: #86229 (comment)
Bugsquad edit: 20231218_MRP_StyleboxC#ReferenceCrash.zip
The text was updated successfully, but these errors were encountered: