search

azunite / gyp

Automatically exported from code.google.com/p/gyp
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Cached command results are sometimes wrong when ran in parallel #420

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?

It's kind of hard to reliably reproduce this, but please let me explain
the symptom and possible suspects.

I regularly build Chromium on Linux. I occasionally see an error from
/usr/bin/ld saying "the flag `--icf=none' is unknown". (This does not
happen so often, and regyp sometimes fixes the issue but the issue
sometimes persists.)

This should not happen because I should be using gold all the time
and /usr/bin/ld should not be invoked at all. But apparently it was
called.

After digging a little bit, I found that the path contained in the "-B"
flag of ldflags was incorrect. The path to binutils directory should be:

    /.../home/yutak/work/Chromium/third_party/binutils/...

but it actually was:

    /.../home/yutak/third_party/binutils/...

which did not exist. This was why the system ld was called as a fallback.

Another finding was that, if I ran gyp with --no-parallel, this error
magically disappeared.

I looked at the code of input.py, and found that |cached_command_results|
is used and updated by multiple threads without locking (if I'm not
mistaken). Apparently <(DEPTH) is triggering a shell command and it's
used repeatedly, thus if there is a race in read/write of
cached_command_results, I can explain the symptom pretty well.

So I think this is a bug in input.py.

What version of the product are you using? On what operating system?

Chromium, Linux

Original issue reported on code.google.com by yutak@chromium.org on 25 Apr 2014 at 9:10

GoogleCodeExporter commented 9 years ago 
Perhaps this might disappear or at least be mitigated with r1911.
yutak@, can you see the same issue with gyp r1911 (or later)?

CCed reviewers of r1911 just in case.

Original comment by yukawa@chromium.org on 2 May 2014 at 12:47

GoogleCodeExporter commented 9 years ago 
Chromium didn't actually have the change that r1911 reverted rolled into it 
yet, so if you are seeing this problem in chromium then it already existed and 
r1911 isn't going to improve matters.

Original comment by torne@chromium.org on 2 May 2014 at 12:49