Repository navigation
Headless editor crashes in WorldScape shutdown on Windows #1402
Description
Tested versions
- Unmodified master a7e798c (
26.3.beta.2.custom_build.a7e798cf7, clean checkout): 6/6 crashes. - Original test binary at 7d4d64c: 3/3 crashes.
- PR Fix WorldScape headless editor shutdown crash on Windows #1400 build at 01d462e: exits 0 with empty stderr for all three frame counts (built with
tests=yesadditionally).
System information
Windows 10 Pro 22H2 x64, build 19045.7417; AMD Ryzen 9 7950X3D; headless mode. MSVC 14.51.36231; Python 3.11 / SCons 4.10.1.
Issue description
Found during automated headless testing. Manual GUI closing has not been reproduced here.
Master crashes on shutdown with 0xC0000005 (3221225477). Expected: clean exit 0. Reproduced at 10, 120, and 600 frames, then repeated with a fresh self-contained editor profile: 6/6 crashes, each using a fresh project. No scene, script, or WS3D node is needed.
Matching stack from master:
Node::queue_free (scene/main/node.cpp:3478)
ChannelPackerDialog::`scalar deleting destructor'
Node::_notification (scene/main/node.cpp:304)
WorldScape3DMenu::_notification_backwardv (modules/worldscape_3d/editor/menu.h:46)
predelete_handler (core/object/object.cpp:2353)
SceneTree::_flush_delete_queue (scene/main/scene_tree.cpp:1610)
SceneTree::finalize (scene/main/scene_tree.cpp:862)
Related fix: #1400. Reproduction copied from the PR comment.
Steps to reproduce
- Build the unmodified master commit above:
python -m SCons platform=windows target=editor arch=x86_64 debug_symbols=yes -j24
- Create
repro/project.godotwith the contents below. - Run in PowerShell:
& .\bin\redot.windows.editor.x86_64.exe --headless --editor --path .\repro --quit-after 10 --max-fps 60
$LASTEXITCODEAlso reproduced with --quit-after 120 and --quit-after 600.
Minimal reproduction project (MRP)
Only repro/project.godot is needed:
config_version=5
[application]
config/name="Shutdown reproduction"
Activity
OldDev78 commentedon Sep 10, 2026
@dominicbytes can you please check if/how often the crash happens using the branch from #1404?
dominicbytes commentedon Sep 12, 2026
Yes, 1404 alone does not solve the problem 1400 solves. The crash from 1400 happens with 1404 in there. But 1404 fixes a different bug, since 1400 alone doesn't solve what you fixed in 1404. Both are good and neither conflicts with the other.
dominicbytes commentedon Sep 25, 2026
Additional reproduction and native diagnosis for official 26.3-rc.1, commit
704b10a8e178949b7bc6931a5417ce6a1cabb27f, on Windows 10 build 19045 x86-64.The crash remains reproducible with no addons, scripts, scenes or WorldScape node in the project. Fresh/cached project state and both quit modes were tested outside sandbox restrictions, with APPDATA/LOCALAPPDATA/TEMP/TMP redirected to disposable test profiles:
--quit--quit--quit-after 180--quit-after 1804f5b14aba)704b10a8e)0xC00000050xC00000050xC00000050xC0000005Both filesystem scan and editor layout initialization complete before each 26.3 crash. The runner checks the native process exit, has a 45-second cap, and observed no timeout or residual child process in these cases. Wrapper, real executable and bundled DLL identities were preserved across the final repeated matrix.
Minimal
project.godot:Reproduction (with the official executable pair in the same directory):
Native findings: LLDB 21.1.6 catches the official real executable in
ntdll!RtlEnterCriticalSection+13, with the critical-section argument0xFEEEFEEEFEEF0056. The official engine frames lack usable symbols. An independently built, unmodified704b10aoptimized editor with embedded symbols reproduces the same shutdown failure family:The actual
SceneTree::finalizereceiver is valid. The invalid receiver above comes from a freed child:_editor_decal_timeris parented toWorldScape3DUI; Node PREDELETE recursively deletes children before the parent's C++ destructor runs. The destructor subsequently callsqueue_free()through the stale timer pointer, reading its poisoneddata.tree.An ordinary run of that same symbolized binary, without LLDB or
--disable-crash-handler, also exits0xC0000005; its built-in symbolized crash trace instead reachesChannelPanel::~ChannelPanel()atmodules/worldscape_3d/editor/menu/channel_packer.cpp:426._wh_hboxand its controls are likewise child nodes already handled by Node PREDELETE. A timer-only change would leave this second observed path.This supports the child-lifetime cleanup addressed by #1400. The current candidate at
b76c7aab89353428ce6393d44c53e740861d5dc8is being tested separately; these results do not yet certify that candidate.Build qualification: the symbolized reproducer above uses Clang 21.1.6/LLVM-MinGW 20251118, production optimization/ThinLTO, D3D12 and AccessKit, with optional static ANGLE omitted after a dependency ABI mismatch. It is a source diagnostic comparison, not an exact reproduction of the official build recipe. A separate build with ANGLE enabled has compiled using its archive's matching toolchain; runtime before/after checks are pending. Windows 11, Linux desktop and graphical-editor regression checks are not claimed here.
Official real editor SHA-256:
9F495834A065CE5715A58685793E07A9D1FA929BEACC7532F518F6CDF717B28D.Symbolized diagnostic editor SHA-256:
A97A8E9CFF661DBFD728508EC11EFED2CC28A2CB103D2C1BCE17C9A56DA5D857.This update was prepared with Codex assistance from fresh automated process tests, native debugger output and pinned source inspection. Raw dumps, local profiles and private paths are not included.
qrcodeconsole commentedon Oct 22, 2026
Also seeing this on Windows 11 (10.0.26300) with the official 26.3.stable build (85e5203), during automated
--headless --importruns. An empty project with onlyproject.godotreproduces it in about half of the imports (10 of 20); each crash comes right after "Loading editor layout" finishes, exit code 0xC0000005. Thanks for the fix in #1541. We'll confirm once 26.4 is out.