gn gen failure on Windows

132 views
Skip to first unread message

Wyatt Hepler

unread,
Apr 27, 2021, 1:08:43 PM4/27/21
to gn-...@chromium.org
Hello,
I am running into problems with GN on Windows for Pigweed. I get an error about a file created with generate_file being used by another process during gn gen.

Here's the summarized error message:

$ gn gen 'C:\<build_dir>' --color=always --check --fail-on-unused-args [9200:0426/144652.603:ERROR:file_writer.cc(40)] CreateFile failed for path C:/<build_dir>/<toolchain>/gen/<file_path> The process cannot access the file because it is being used by another process. (0x20) ERROR Unable to write file. I was writing "C:/<build_dir>/<toolchain>/gen/<file_path>".


(example build failure here, though you may not have access)

These errors started occurring when I switched some generate_file commands from the default toolchain to a non-default toolchain (CL). They only occur on Windows for one internal project, and happen about half of the time. They never happen if the generate_file commands are in the default toolchain.

A second, possibly related issue occurs after gn gen succeeds. The directory for an output from an action_foreach does not exist when it runs on Windows, but only for this one project. The directory does exist on Linux or Mac. That is easy to work around -- I just create the parent directory of the output file before creating it (perhaps we should be doing that anyway). Just odd that this only occurs for one project's build on one platform.

Has anyone seen issues like these on Windows?

Thanks,
Wyatt

Brett Wilson

unread,
Apr 27, 2021, 1:21:22 PM4/27/21
to Wyatt Hepler, gn-dev
I have not seen this. The main Windows GN user is Chromium and it doesn't look like they use the generate_file target type.

Normally for this type of error I would suspect virus checking. I see that this uses WriteFileIfChanged() which will open the file, read it in, and compare the contents. This is important so the timestamps are only updated for new contents which prevents rebuilds. What I've heard happen in other cases is that the first open triggers a virus scan which starts and the rapid close + reopen is fast enough that the virus checker still has the file open. Something similar might also happen for local syncing programs like Dropbox.

Maybe see if you can exclude the directories from scanning?

Brett

Wyatt Hepler

unread,
Apr 27, 2021, 4:01:55 PM4/27/21
to Brett Wilson, Rob Mohr, gn-dev
Virus scanning could be the culprit. We're running this in LUCI, and I'm not sure what that environment looks like. +Rob Mohr, do you happen to know if there is virus checking that could be running on our repo in LUCI?

The odd thing is that this error always happens with the exact same generated file. I've never seen it with other files. I would expect something like virus checking or syncing programs to cause failures randomly for different files.

We can workaround this for now. Hopefully this issue will remain isolated to this one project.

Thanks,
Wyatt

ang zh

unread,
Nov 20, 2023, 10:54:23 PM11/20/23
to gn-dev, Wyatt Hepler, gn-dev, Brett Wilson, Rob Mohr
I have also encountered this issue, and I know the reason: the file path exceeds the maximum limit of 260 characters (Windows max limit).
 I don't know how to solve it? Modifying the registry doesn't seem to work.

Nico Weber

unread,
Nov 26, 2023, 8:25:52 PM11/26/23
to ang zh, gn-dev, Wyatt Hepler, Brett Wilson, Rob Mohr
The pragmatic thing is to put your checkout at a fairly short path (`c:\src\myproject`).

You can try to add long path support to all tools you depend on, but that'll be a lot of work in my experience. 
Reply all
Reply to author
Forward
0 new messages