Bug 206565 - [AppleWin][Cygwin Perl][EWS] preprocessor.pm is occasionally failing to spawn a child process
Summary: [AppleWin][Cygwin Perl][EWS] preprocessor.pm is occasionally failing to spawn...
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: Bindings (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-01-21 18:10 PST by Fujii Hironori
Modified: 2020-09-22 14:08 PDT (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fujii Hironori 2020-01-21 18:10:36 PST
[AppleWin][Cygwin Perl][EWS] preprocessor.pm is occasionally failing to spawn a child process

EWS are observing AppleWin binding generation errors like:

> Processing document /home/buildbot/worker/Windows-EWS/build/Source/WebCore/svg/SVGAltGlyphDefElement.idl did not generate anything at /home/buildbot/worker/Windows-EWS/build/Source/WebCore/bindings/scripts/CodeGenerator.pm line 247.

> Could NOT find interface definition for Node in ./dom/Node.idl at /home/buildbot/worker/Windows-EWS/build/Source/WebCore/bindings/scripts/CodeGenerator.pm line 502.

Bug 84274 is the past attempt to fix the issue.
AppleWin should use Win32 Perl as well as WinCairo does.
Comment 1 Fujii Hironori 2020-01-24 17:09:33 PST
make_names.pl failed today.

https://ews-build.webkit.org/#/builders/10/builds/4744
https://bugs.webkit.org/attachment.cgi?id=388672&action=prettypatch
https://bugs.webkit.org/show_bug.cgi?id=206416

> xlinkattrs.in
> Generating ../../DerivedSources/WebCore/XMLNSNames.cpp, ../../DerivedSources/WebCore/XMLNSNames.h
>  Failed to read names from file: C:/cygwin/home/buildbot/worker/Windows-EWS/build/Source/WebCore/xml/xmlnsattrs.in at C:/cygwin/home/buildbot/worker/Windows-EWS/build/Source/WebCore/dom/make_names.pl line 331.

It also invoke cc to preprocess.
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/dom/make_names.pl

This seems a variant of this issue.
Comment 2 Fujii Hironori 2020-01-29 19:31:25 PST Comment hidden (obsolete)
Comment 3 Radar WebKit Bug Importer 2020-01-29 19:32:12 PST
<rdar://problem/59016784>
Comment 4 Fujii Hironori 2020-01-29 19:34:24 PST Comment hidden (obsolete)
Comment 5 Fujii Hironori 2020-02-16 20:18:21 PST
It's still failing today.

> Could NOT find interface definition for SVGGradientElement in ./svg/SVGGradientElement.idl at /home/buildbot/worker/Windows-EWS/build/Source/WebCore/bindings/scripts/CodeGenerator.pm line 502.

https://ews-build.webkit.org/#/builders/10/builds/7486
Comment 6 Fujii Hironori 2020-07-05 12:52:04 PDT
It's still failing today.

>  Processing document /home/buildbot/worker/Windows-EWS/build/Source/WebCore/svg/SVGSwitchElement.idl did not generate anything at /home/buildbot/worker/Windows-EWS/build/Source/WebCore/bindings/scripts/CodeGenerator.pm line 247.

https://ews-build.webkit.org/#/builders/10/builds/29815/steps/22/logs/stdio
Comment 7 Fujii Hironori 2020-07-05 14:41:10 PDT
(In reply to Fujii Hironori from comment #0)
> AppleWin should use Win32 Perl as well as WinCairo does.

Or, how about using 64bit Cygwin? It seems that EWS is using 32bit cygwin.
Comment 8 Per Arne Vollan 2020-07-06 11:18:03 PDT
(In reply to Fujii Hironori from comment #7)
> (In reply to Fujii Hironori from comment #0)
> > AppleWin should use Win32 Perl as well as WinCairo does.
> 
> Or, how about using 64bit Cygwin? It seems that EWS is using 32bit cygwin.

I think we're using 64-bit Cygwin, if I am not mistaken?
Comment 9 Fujii Hironori 2020-07-06 12:54:35 PDT
I thought it's 32bit just because the log has C:\cygwin not C:\cygwin64, and CygwinDownloader downloads setup-x86.exe.
Comment 10 Aakash Jain 2020-07-06 13:01:54 PDT
Seems like 64-bit.

buildbot@ews215 ~$ uname -m
x86_64

See: https://stackoverflow.com/a/22689191
Comment 11 Per Arne Vollan 2020-07-06 13:28:13 PDT
(In reply to Fujii Hironori from comment #9)
> I thought it's 32bit just because the log has C:\cygwin not C:\cygwin64, and
> CygwinDownloader downloads setup-x86.exe.

I think we just kept the Cygwin folder name when upgrading to 64-bit, since I believe Win EWS on Cygwin depends on this.
Comment 12 Fujii Hironori 2020-09-14 13:42:50 PDT
This issue is still happening.

https://ews-build.webkit.org/#/builders/10/builds/36343

> Processing document /home/buildbot/worker/Windows-EWS/build/Source/WebCore/Modules/webaudio/PannerNode.idl did not generate anything. at /home/buildbot/worker/Windows-EWS/build/Source/WebCore/bindings/scripts/CodeGenerator.pm line 196.

I'm going to try some ideas.

* Use cl.exe to preprocess even for Cygwin
* Sleep random seconds before retrying process spawning
Comment 13 Fujii Hironori 2020-09-14 14:13:16 PDT
I realized GENERATE_DOM_NAMES is already using CMAKE_CXX_COMPILER to preprocess.
CMAKE_CXX_COMPILER is cl.exe in AppleWin Cygwin builds.
However, looking at Comment 1 failure, spawning cl.exe also failed.
Comment 14 Fujii Hironori 2020-09-14 17:24:19 PDT
It seems that GENERATE_BINDINGS is also using cl.exe for preprocessing in AppleWin Cygwin builds.

Umm, is this a problem of spawning a win32 process in Cygwin?
Can using Cygwin gcc solve the issue?
Comment 15 Fujii Hironori 2020-09-14 21:49:15 PDT
Another idea:

* No so many files are using preprocessor directives nowadays. Skip spawning a process for files which doesn't have "#if" by grepping "#if" in preprocessor.pm.
Comment 16 Fujii Hironori 2020-09-15 14:45:51 PDT
r267101 stops cygpath process spawning. I'm going to watch AppleWin EWS for a week.

  Bug 216527 – preprocessor.pm: Use Cygwin::win_to_posix_path and Cygwin::posix_to_win_path instead of cygpath command
Comment 17 Fujii Hironori 2020-09-22 14:08:34 PDT
I've observed no failures since r267101. Closed.