Editor command line --doctool option stalls on generating new docs

[MylesScholz]

Tested versions

• Reproducible in: 4.2.2.stable [15073af], 4.3.rc [3e0c10d]

System information

Godot v4.3.rc (3e0c10d) - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2060 with Max-Q Design (NVIDIA; 30.0.15.1278) - AMD Ryzen 9 4900HS with Radeon Graphics (16 Threads)

Issue description

When running the editor with the --doctool option from the command line, the program loads the docs and erases the old docs, but it stalls for >1 hour on "Generating new docs...". I assume this is a long-running operation, but the wait time seems excessively long, and there is no indication of progress.

I was looking into updating some class reference documentation by following this guide, but it didn't mention how long the doctool is expected to run or if there were any required build options for the doctool to work.

Steps to reproduce

0. Clone the Godot repository
1. Build with scons .
2. Run .\bin\godot.windows.editor.x86_64.exe --doctool
3. Wait...

Minimal reproduction project (MRP)

N/A

[bruvzg]

.\bin\godot.windows.editor.x86_64.exe --doctool

Always use .console.exe instead of GUI one when running from command line. Most likely it does not stall, it's just not redrawing command prompt since app is detached from console and shell can't know when GUI app is finished (you can press Enter to force redaw it).

[MylesScholz]

I ran .\bin\godot.windows.editor.x86_64.console.exe --doctool on the 4.3.rc [3e0c10d] version, and it's still going after over an hour. I tried pressing Enter several times, but that didn't do anything. I'll leave it running for longer to see if it's just slow. I don't know if it's supposed to create the files as it goes, but it hasn't created or modified any, just deleted the existing ones.

[MylesScholz]

It's been running for 9 hours now with no change.

[MylesScholz]

I ran the latest version (4.3.rc [3978628]) with gdb, and it seems to get stuck on editor/doc_tools.cpp:1599:

Ref<FileAccess> f = FileAccess::open(save_file, FileAccess::WRITE, &err);

The particular class that it gets stuck on is inconsistent, and sometimes it gets partially through modifying some files.

[Calinou]

Do you have the Godot source repository on a symbolic link, junction or network drive?

[MylesScholz]

I don't believe so. It's just on my C drive.

[AThousandShips]

Can you confirm that instance of the editor is running? Even a dead process lingering in the background? Maybe reboot just to make sure.

[MylesScholz]

Yes, the editor and the console version are running but not doing anything. I will try digging into the FileAccess::open() call with gdb to see where the problem is more specifically.

[AThousandShips]

Check details to see if orphan processes are running

[MylesScholz]

I'm not sure how to check for orphan processes, but here is the details page:

[MylesScholz]

I've isolated the stall to drivers/windows/file_access_windows.cpp:197:

f = _wfsopen((LPCWSTR)(path.utf16().get_data()), mode_string, is_backup_save_enabled() ? _SH_SECURE : _SH_DENYNO);

Interestingly, sometimes when stepping through the program with gdb, it works all the way through. That might suggest it's a concurrency issue.