Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1407043010:
GN(android): Add work-around for "project database corrupted" error (Closed)
|
Created:
5 years, 1 month ago by agrieve Modified:
5 years, 1 month ago Reviewers:
Yaron CC:
chromium-reviews, klundberg+watch_chromium.org, mikecase+watch_chromium.org, yfriedman+watch_chromium.org, jbudorick+watch_chromium.org Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionGN(android): Add work-around for "project database corrupted" error
Happens randomly when compiling java with enable_incremental_javac=true.
BUG=551449
Committed: https://crrev.com/b09587112b3c257f02b9bca2ad19d1a48919b74d
Cr-Commit-Position: refs/heads/master@{#357904}
Patch Set 1 #
Total comments: 2
Patch Set 2 : add print #
Depends on Patchset: Messages
Total messages: 14 (3 generated)
Description was changed from ========== GN(android): Add work-around for "project database corrupted" error Happens randomly when compiling java with enable_incremental_javac=true. BUG=551449 ========== to ========== GN(android): Add work-around for "project database corrupted" error Happens randomly when compiling java with enable_incremental_javac=true. BUG=551449 ==========
agrieve@chromium.org changed reviewers: + yfriedman@chromium.org
On 2015/11/04 16:13:51, agrieve wrote: > mailto:agrieve@chromium.org changed reviewers: > + mailto:yfriedman@chromium.org Not exactly a proper fix, but probably not worth spending time on a proper fix since the work-around is easy enough.
Have you repro'd locally and seen that a second build Just Works? https://codereview.chromium.org/1407043010/diff/1/build/android/gyp/javac.py File build/android/gyp/javac.py (right): https://codereview.chromium.org/1407043010/diff/1/build/android/gyp/javac.py#... build/android/gyp/javac.py:249: # Work-around for a bug in jmake (http://crbug.com/551449). yowza - now that's a hack! There's also no guarantee that the second attempt will work. At a minimum, please add a log that we're retrying. Can you file an upstream bug against jmake?
I hit this error two days in a row now :(. Did verify that it unbroke my local state. https://codereview.chromium.org/1407043010/diff/1/build/android/gyp/javac.py File build/android/gyp/javac.py (right): https://codereview.chromium.org/1407043010/diff/1/build/android/gyp/javac.py#... build/android/gyp/javac.py:249: # Work-around for a bug in jmake (http://crbug.com/551449). On 2015/11/04 16:45:13, Yaron wrote: > yowza - now that's a hack! > There's also no guarantee that the second attempt will work. At a minimum, > please add a log that we're retrying. > > Can you file an upstream bug against jmake? It should always work the second time since there is now no longer a pdb file to load (error happens at start-up). Add a log message so we can at least get a feel for how often it's triggered. Filed: https://github.com/pantsbuild/jmake/issues/22
lgtm
The CQ bit was checked by agrieve@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1407043010/20001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1407043010/20001
Message was sent while issue was closed.
Committed patchset #2 (id:20001)
Message was sent while issue was closed.
Patchset 2 (id:??) landed as https://crrev.com/b09587112b3c257f02b9bca2ad19d1a48919b74d Cr-Commit-Position: refs/heads/master@{#357904}
Message was sent while issue was closed.
On 2015/11/04 21:37:44, commit-bot: I haz the power wrote: > Patchset 2 (id:??) landed as > https://crrev.com/b09587112b3c257f02b9bca2ad19d1a48919b74d > Cr-Commit-Position: refs/heads/master@{#357904} With this change in place, I am no longer seeing valid compiler failures using GYP based ninja builds (i.e. I can edit a java file to introduce an obvious error and compilation succeeds). Removing this change will cause the compiler to start showing valid errors again. Is there a bug tracking this problem already? If this is causing the try-bots to miss real errors, then it's possible that there are build breaks hidden by this change which will surface when it is reverted. Joe
Message was sent while issue was closed.
A revert of this CL (patchset #2 id:20001) has been created in https://codereview.chromium.org/1411183007/ by jbudorick@chromium.org. The reason for reverting is: This also popped up on WebRTC: https://code.google.com/p/webrtc/issues/detail?id=5169.
Message was sent while issue was closed.
On 2015/11/05 18:06:22, joedow wrote: > On 2015/11/04 21:37:44, commit-bot: I haz the power wrote: > > Patchset 2 (id:??) landed as > > https://crrev.com/b09587112b3c257f02b9bca2ad19d1a48919b74d > > Cr-Commit-Position: refs/heads/master@{#357904} > > With this change in place, I am no longer seeing valid compiler failures using > GYP based ninja builds (i.e. I can edit a java file to introduce an obvious > error and compilation succeeds). Removing this change will cause the compiler > to start showing valid errors again. > > Is there a bug tracking this problem already? If this is causing the try-bots > to miss real errors, then it's possible that there are build breaks hidden by > this change which will surface when it is reverted. > > Joe After looking a bit more, the problem is that the change above catches all exceptions and retries on a subset. The code should rethrow any unhandled exceptions.
Message was sent while issue was closed.
On 2015/11/05 18:48:19, joedow wrote: > On 2015/11/05 18:06:22, joedow wrote: > > On 2015/11/04 21:37:44, commit-bot: I haz the power wrote: > > > Patchset 2 (id:??) landed as > > > https://crrev.com/b09587112b3c257f02b9bca2ad19d1a48919b74d > > > Cr-Commit-Position: refs/heads/master@{#357904} > > > > With this change in place, I am no longer seeing valid compiler failures using > > GYP based ninja builds (i.e. I can edit a java file to introduce an obvious > > error and compilation succeeds). Removing this change will cause the compiler > > to start showing valid errors again. > > > > Is there a bug tracking this problem already? If this is causing the try-bots > > to miss real errors, then it's possible that there are build breaks hidden by > > this change which will surface when it is reverted. > > > > Joe > > After looking a bit more, the problem is that the change above catches all > exceptions and retries on a subset. The code should rethrow any unhandled > exceptions. Derp. Sorry about that! Thanks for reverting. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
