RESOLVED FIXED 215054
Prevent multiple invocations of generate-message-receiver.py
https://bugs.webkit.org/show_bug.cgi?id=215054
Summary Prevent multiple invocations of generate-message-receiver.py
Keith Rollin
Reported 2020-08-01 00:44:21 PDT
WebKit/DerivedSources.make is written such that generate-message-receiver.py can be invoked N times, where N is the value passed to -j. This results in the N invocations of generate-message-receiver.py trying trying to generate the same set of files at the same time, possibly leading to their being corrupted. We have reports of generated files starting with a 4K block of NULs, and this contention may be causing it. Address this by using a "pattern rule" in the makefile, which is documented in GNU make's documentation as the approach to take when there is one build rule that creates multiple outputs, as is the case here. See also Bug 166814 and <http://trac.webkit.org/changeset/210507>.
Attachments
Patch (3.66 KB, patch)
2020-08-01 00:47 PDT, Keith Rollin
no flags
Keith Rollin
Comment 1 2020-08-01 00:44:26 PDT
Keith Rollin
Comment 2 2020-08-01 00:47:10 PDT
EWS
Comment 3 2020-08-01 10:54:49 PDT
Committed r265178: <https://trac.webkit.org/changeset/265178> All reviewed patches have been landed. Closing bug and clearing flags on attachment 405775 [details].
Darin Adler
Comment 4 2020-08-01 13:40:25 PDT
Comment on attachment 405775 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=405775&action=review > Source/WebKit/DerivedSources.make:257 > +MESSAGES_FILES := $(addsufix Messages.h,$(notdir $(MESSAGE_RECEIVERS))) The "addsuffix" here was missing an "f" so this didn’t quite work. Also, I did some further research, and I think a better solution is a "grouped target" rather than a pattern rule.
Darin Adler
Comment 5 2020-08-01 14:08:10 PDT
I put a fix for those things into bug 215064.
Keith Rollin
Comment 6 2020-08-02 18:09:24 PDT
I commented in <rdar://problem/63595589> that "grouped targets" won't work.
Keith Rollin
Comment 7 2020-08-02 18:10:32 PDT
That missing "f" was from the original code. I wonder how long it had been broken that way.
Keith Rollin
Comment 8 2020-08-02 18:12:32 PDT
Issue was introduced May 6 with r261254. The first report of the generated file corruption was on May 25.
Darin Adler
Comment 9 2020-08-02 19:30:16 PDT
That revision replaced the existing pattern rule with a non-pattern rule! I think we found the root cause.
Note You need to log in before you can comment on or make changes to this bug.