proguard/deobfuscation pegging Kitkat bots at 100% CPU |
||||||||||||||||||||
Issue descriptionHey! I'm not sure if this is a Trooper issue or what, but I'm very confused, hopefully you can at least point me in the right direction. I've got two KitKat builders that have failed their last two unit_tests and components_unittests targets https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/android-kitkat-arm-rel https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/KitKat%20Phone%20Tester%20%28dbg%29 I don't understand though, why they're failing. Looking at an old successful run https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8937564530967616976/+/steps/components_unittests_on_Android_device_Nexus_5/0/stdout and a new failing run: https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8937554695184194864/+/steps/components_unittests_on_Android_device_Nexus_5/0/stdout I don't see the difference.. I see that on https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/android-kitkat-arm-rel/8791 under components_unittests there's "shard #2 (failed)" but I don't get what that means.. https://chromium-swarm.appspot.com/task?id=3f76c62068df1e10&refresh=10&show_raw=1 Any help is appreciated!
,
Aug 21
I heard that swarming pushes happen on Tuesdays, and today is a Tuesday! Is it possible the push happened a little before ~12:30 pm today?
,
Aug 22
There does look to be an outage wrt android bots in swarming. Bots are falling offline: http://shortn/_1MMrUNTcod It's unclear if it's the same cause for the failures you're seeing here. The majority seems to be a timeout when pushing data deps to the device. I'm actively investigating.
,
Aug 22
The underlying cause for a lot of the android failures we're seeing (including a backed-up CQ https://ci.chromium.org/p/chromium/builders/luci.chromium.try/android-kitkat-arm-rel?limit=200) is an overloaded CPU. The host machines that run the tests are getting pegged at 100% cpu usage, which causes a whole bunch of things (tests included) to fall over or freeze. For example: http://shortn/_cpqqyvmyjm And that appears to be happening for almost every kitkat bot. Logged onto one of the bots, and it appears the source of the cpu load is a whole bunch of java proceses: chrome-bot@build94-b4:(Linux 14.04):~$ ps aux | grep java chrome-+ 450 12.4 0.3 9017124 76984 ? Sl 12:14 41:23 java -classpath bin/../lib.java/build/android/stacktrace/java_deobfuscate.jar:bin/../lib.java/build/android/stacktrace/java_deobfuscate.jar:bin/../lib.java/third_party/proguard/proguard.jar:bin/../lib.java/third_party/proguard/retrace.jar -enableassertions org.chromium.build.FlushingReTrace /b/swarming/w/ir/out/Release/apks/ChromeSyncShellTest.apk.mapping chrome-+ 586 7.8 0.8 9017124 203284 ? Sl 12:07 26:31 java -classpath bin/../lib.java/build/android/stacktrace/java_deobfuscate.jar:bin/../lib.java/build/android/stacktrace/java_deobfuscate.jar:bin/../lib.java/third_party/proguard/proguard.jar:bin/../lib.java/third_party/proguard/retrace.jar -enableassertions org.chromium.build.FlushingReTrace /b/swarming/w/ir/out/Release/apks/ChromePublicTest.apk.mapping chrome-+ 591 7.7 0.8 9017124 215524 ? Sl 12:07 26:14 java -classpath bin/../lib.java/build/android/stacktrace/java_deobfuscate.jar:bin/../lib.java/build/android/stacktrace/java_deobfuscate.jar:bin/../lib.java/third_party/proguard/proguard.jar:bin/../lib.java/third_party/proguard/retrace.jar -enableassertions org.chromium.build.FlushingReTrace /b/swarming/w/ir/out/Release/apks/ChromePublicTest.apk.mapping .... and many more. 78 in total. So some proguard/deobfuscation process is hogging the CPU. And it started doing so recently. +agrieve/tiborg/digit: Any idea if something changed recently in that area? If so, let's revert it. Things are actively dying off, and I'm having a hard time keeping a handle on it. + clank sheriffs FYI
,
Aug 22
We recently added synchronized proguarding for bundles (4bbde2a8f25943e648e568d3e208d28926481e0e). That is hard to revert at this point since other changes landed on top of it. I'm also not sure whether it is the culprit since I don't know what these deobfuscation/retracing commands do. The synchronized proguarding added three proguarding steps that each take ~2 minutes on my machine to execute. For testing purposes we could try to disable proguarding on bundles to see if that fixes something (set proguard_enabled = false on all bundles, e.g. here https://cs.chromium.org/chromium/src/chrome/android/BUILD.gn?rcl=5dc92e19e7d6a7e23df906529ca55bbfb170d5d4&l=1744).
,
Aug 22
,
Aug 22
jonross@ pointed out that https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/android-kitkat-arm-rel/8791 seems to be the first failing build. The oldest revision in the build is from yesterday. However, synchronized proguarding was added three weeks ago. Seems unlikely to be the culprit.
,
Aug 22
,
Aug 22
Issue 876748 has been merged into this issue.
,
Aug 22
Keep in mind that a single host in our infra can run up to 7 different tests simultaneously. So any load you test out locally... you might have to septuple that. Additionally, maybe a given test isn't cleaning up after itself properly and leaving proguard procs around? Anyway, I've taken the kitkat bot off the CQ in https://chromium-review.googlesource.com/c/chromium/src/+/1185229 while we investigate.
,
Aug 22
And why aren't we seeing the same thing on the M CQ bot: https://ci.chromium.org/p/chromium/builders/luci.chromium.try/android-marshmallow-arm64-rel?limit=200 What could the tests be doing differently wrt proguard on M...?
,
Aug 22
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/80a5f1d80b3c9a08a519405a3d98661bb383471a commit 80a5f1d80b3c9a08a519405a3d98661bb383471a Author: Ben Pastene <bpastene@chromium.org> Date: Wed Aug 22 16:08:29 2018 Demote android-kitkat-arm-rel to 100% CQ experiment. It's not doing well. https://ci.chromium.org/p/chromium/builders/luci.chromium.try/android-kitkat-arm-rel?limit=200 Fortunately, the M bot is ok: https://ci.chromium.org/p/chromium/builders/luci.chromium.try/android-marshmallow-arm64-rel?limit=200 NOTRY=true Bug: 876539 Change-Id: Icb9770bf0df60fe28ad92dfabeb0c5c8f14f30af Reviewed-on: https://chromium-review.googlesource.com/1185229 Commit-Queue: Ben Pastene <bpastene@chromium.org> Reviewed-by: Dirk Pranke <dpranke@chromium.org> Reviewed-by: John Budorick <jbudorick@chromium.org> Cr-Commit-Position: refs/heads/master@{#585029} [modify] https://crrev.com/80a5f1d80b3c9a08a519405a3d98661bb383471a/infra/config/branch/cq.cfg
,
Aug 22
Issue 876756 has been merged into this issue.
,
Aug 22
,
Aug 22
,
Aug 22
I don't know of anything that's changed wrt to this code. The processes are quite expensive RAM-wise (500MB per process when I added them): https://cs.chromium.org/chromium/src/build/android/pylib/symbols/deobfuscator.py?rcl=580c69963c034832eabfa88f266e6408289e769e&l=130 There can be up to 4 per test, but even if 7 tests at a time run, that's not close to 78.
,
Aug 22
re #11 - certainly a mystery. There's nothing OS-specific about obfuscation.
,
Aug 22
,
Aug 22
Note that one change on this bot recently is that the webkit_layout_tests step was un-broken in Issue 875172 . Not sure it is related but linked to it just in case.
,
Aug 22
webkit_layout_tests currently only runs on the K dbg tester, and not the release CQ tester... Though it triggers tests into the same pool, so it's possible there could be some cross-contamination going on, but I'd be surprised. And not surprisingly, the jump in cpu usage also correlates with jump in mem usage: mem: http://shortn/_cbsOFd21kM cpu: http://shortn/_TdcuubRdes
,
Aug 22
The Marshmallow 64 bit Tester is seeing a small number of test flakes. I think they look pretty similar to the KitKat failures we're seeing here. https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Marshmallow%2064%20bit%20Tester unit_tests target of https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Marshmallow%2064%20bit%20Tester/23419 1 failing shard that never gets to running tests https://chromium-swarm.appspot.com/task?id=3f7b757dfb7c9710&refresh=10
,
Aug 22
Narrowing it down, https://chromium-swarm.appspot.com/task?id=3f76b12f9122b710 is a pretty good starting point for when the problem started to first appear. That test contains many "deobfuscator: Timed out." warnings, which we're pretty sure is what's causing the proguard explosion. That task (though it ran on the CQ) ran at base revision r2eb57d5b5ea08f7bf15a67056fa03b2b6aabfd4b. The culprit likely lays within the past few commits starting from there: https://chromium.googlesource.com/chromium/src/+log/2eb57d5b5ea08f7bf15a67056fa03b2b6aabfd4b We've spotted a few candidates (namely https://chromium-review.googlesource.com/c/chromium/src/+/1179251) and are testing them out.
,
Aug 22
FWIW, the task in #22 contains quite a few dalvik errors like "unable to resolve virtual method" in the logcat when proguard timesout: https://luci-logdog.appspot.com/logs/chromium/android/swarming/logcats/3f76b12f9122b711/+/logcat_logcat_org.chromium.chrome.browser.TabThemeTest.testThemeColorIsCorrect_20180821T190814-UTC_022b169f0c33f7a5 Could be related, but I'm not sure... a bit out of my depth at this point. Fortunately, repro'ing locally isn't very hard, so hopefully we can narrow down what exactly broke it soon.
,
Aug 22
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b81f63ce2e0725921c81fb977d33fe5b95e951b5 commit b81f63ce2e0725921c81fb977d33fe5b95e951b5 Author: John Budorick <jbudorick@chromium.org> Date: Wed Aug 22 19:05:52 2018 android: disable deobfuscation in tests. Deobfuscation appears to be hanging in ways that cause it to peg bots' CPUs and kill test runs. This CL temporarily disables it as a mitigation. Bug: 876539 Change-Id: I6dced1a4c80e630bb701a17eaa8322450661adc5 Reviewed-on: https://chromium-review.googlesource.com/1185294 Reviewed-by: Ben Pastene <bpastene@chromium.org> Commit-Queue: John Budorick <jbudorick@chromium.org> Cr-Commit-Position: refs/heads/master@{#585190} [modify] https://crrev.com/b81f63ce2e0725921c81fb977d33fe5b95e951b5/build/config/android/internal_rules.gni
,
Aug 22
With the change in #24, we've turned off deobfuscation all together. We'll let that sit for a bit and see if things improve and bots stay healthy. (Will probably take a couple hours.) After some repros and local reverts, we believe that https://chromium-review.googlesource.com/c/chromium/src/+/1179251 is the original cause. Though we're not entirely sure how (jbud was tracing proguard's logcat regexs at some point... not sure how far he got there). If the change in #24 does prove helpful, we'll revert crrev.com/c/1179251, then reenable deobfuscation for tests. And if all that goes as planned, we should be in a good place to put android-kitkat-arm-rel back on the CQ. Unfortunately, given how much cleanup and confirmation still needs to be done, that likely won't happen until sometime tomorrow.
,
Aug 22
Is this resolving itself? Any ETA or status update?
,
Aug 22
After #24, bots have stopped dropping offline. But I'm still trying to resuscitate the ones that have died over the past couple days: http://shortn/_XsuKTMApgQ That's proving a bit tricker than I had hoped given the state some of them are in (ie: some are failing to shutdown properly). I'm expecting everything to come back up by eod today. Then we need to decide if we want #24 reverted before putting the K bot back on the CQ. Given the state deobfuscation testing is in, I'm leaning toward keeping it off for now. (ie: we have little guarantee that something like crrev.com/c/1179251 won't cause this again). But I'll let jbud/agrieve decide that. (What benefit does deobfuscation on the CQ give us? Can we live w/o it for an extended period of time?) tl;dr: I'm hoping we can re-enable android-kitkat-arm-rel sometime tomorrow.
,
Aug 22
Issue 876566 has been merged into this issue.
,
Aug 23
Things have just about settled down. Bots are back to being green and happy. I'll plan on adding the K bot back to the CQ first thing tomorrow if things still look good then. (Leaving this bug at P0 until that's been done.)
,
Aug 23
Figured out how to repro the issue locally. 1. Build chrome_public_test_apk with is_java_debug=false 2. run: out/Release/bin/java_deobfuscate out/Release/apks/ChromePublicTest.apk < example-logcat.txt > output.txt The process will just stay pegged at 100% CPU usage. Attached the sample-logcat.txt. I took it from the first timed-out deobfuscation from the logs in #7
,
Aug 23
Smaller repro: echo '12742: LccB;.onDescendantInvalidated (Landroid/view/View;Landroid/view/View;)V' | bin/java_deobfuscate apks/ChromePublicForTest.apk.mapping Obfuscating this class on its own works fine: $ echo 'LccB;.onDescendantInvalidated' | bin/java_deobfuscate apks/ChromePublicForTest.apk.mapping Lorg/chromium/webshare/mojom/ShareService_Internal$ShareServiceShareResponseParamsProxyToResponder;.onDescendantInvalidated I used a local mapping file, so in reality this would deobfuscate to: ViewResourceFrameLayout, which was added in 2eb57d5b5ea08f7bf15a67056fa03b2b6aabfd4b (the commit identified in #22) Full original line was: VFY: unable to resolve virtual method 12742: LccB;.onDescendantInvalidated (Landroid/view/View;Landroid/view/View;)V There are lots of "VFY: unable to resolve virtual method..." lines in the logcats, but this is the only one that has an obfuscated class name in it. So... I don't know the fix yet, but the problem really is that retrace is getting caught in an infinite loop triggered by a kitkat-only VFY message introduced by a recent commit. We might want to consider changing a timeout to instead disable all future attempts rather than skipping the current job and continuing to deobfuscate all future jobs.
,
Aug 23
re: what to do in the meantime - should be fine to re-enable the bot with deobfuscation disabled. Some failures might be hard to debug in the meantime, but I think that's better than having the bot completely disabled.
,
Aug 23
I guess there is nothing what chromium-sheriff can do on this. Removing Sheriff-Chromium.
,
Aug 23
fixing how the java_deobfuscate process gets killed on timeout & adding a repro case to java_deobfuscate_test.py here: https://chromium-review.googlesource.com/c/chromium/src/+/1186542
,
Aug 23
Found that a newer version of retrace doesn't have this bug. CL to update it here: https://chromium-review.googlesource.com/c/chromium/src/+/1187003
,
Aug 23
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ebbac47d5f40c5b1fa472000c042b1fe652cf611 commit ebbac47d5f40c5b1fa472000c042b1fe652cf611 Author: Ben Pastene <bpastene@chromium.org> Date: Thu Aug 23 16:53:54 2018 Revert "Demote android-kitkat-arm-rel to 100% CQ experiment." This reverts commit 80a5f1d80b3c9a08a519405a3d98661bb383471a. Reason for revert: outage over Original change's description: > Demote android-kitkat-arm-rel to 100% CQ experiment. > > It's not doing well. > https://ci.chromium.org/p/chromium/builders/luci.chromium.try/android-kitkat-arm-rel?limit=200 > > Fortunately, the M bot is ok: > https://ci.chromium.org/p/chromium/builders/luci.chromium.try/android-marshmallow-arm64-rel?limit=200 > > NOTRY=true > > Bug: 876539 > Change-Id: Icb9770bf0df60fe28ad92dfabeb0c5c8f14f30af > Reviewed-on: https://chromium-review.googlesource.com/1185229 > Commit-Queue: Ben Pastene <bpastene@chromium.org> > Reviewed-by: Dirk Pranke <dpranke@chromium.org> > Reviewed-by: John Budorick <jbudorick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#585029} TBR=dpranke@chromium.org,bpastene@chromium.org,jbudorick@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: 876539 Change-Id: I3f137fb209f0decfc13be5dab518e9e644e98b8c Reviewed-on: https://chromium-review.googlesource.com/1187084 Reviewed-by: Ben Pastene <bpastene@chromium.org> Reviewed-by: Dirk Pranke <dpranke@chromium.org> Commit-Queue: Ben Pastene <bpastene@chromium.org> Cr-Commit-Position: refs/heads/master@{#585520} [modify] https://crrev.com/ebbac47d5f40c5b1fa472000c042b1fe652cf611/infra/config/branch/cq.cfg
,
Aug 23
Bot's back on the CQ. Lowering pri.
,
Aug 23
,
Aug 23
Post-mortem up at go/chops-pm-94
,
Aug 24
Is this having issues again? Just failed on a recent patch for me: https://ci.chromium.org/p/chromium/builders/luci.chromium.try/android-kitkat-arm-rel/65602
,
Aug 24
#41: that appears to be a different failure mode.
,
Aug 24
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/32813a502d0bc3d725e2445ca326770e6f73bf3c commit 32813a502d0bc3d725e2445ca326770e6f73bf3c Author: John Budorick <jbudorick@chromium.org> Date: Fri Aug 24 15:18:57 2018 android: fix deobfuscator closing + add infinite loop test case. Bug: 876539 Change-Id: Ib28bf55e7213789186b8180904f7317cb5c0d8ce Reviewed-on: https://chromium-review.googlesource.com/1186542 Commit-Queue: John Budorick <jbudorick@chromium.org> Reviewed-by: agrieve <agrieve@chromium.org> Cr-Commit-Position: refs/heads/master@{#585843} [modify] https://crrev.com/32813a502d0bc3d725e2445ca326770e6f73bf3c/build/android/pylib/symbols/deobfuscator.py [modify] https://crrev.com/32813a502d0bc3d725e2445ca326770e6f73bf3c/build/android/stacktrace/java_deobfuscate_test.py
,
Aug 24
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bd3c0e676955a999600b966e2c02bec00dbacabf commit bd3c0e676955a999600b966e2c02bec00dbacabf Author: Andrew Grieve <agrieve@chromium.org> Date: Fri Aug 24 17:19:00 2018 Android: Update version of retrace.jar to 6.0.3 The existing version was found to infinite loop at times. Also moves the jars to CIPD NOTRY=true # windows bot failing Bug: 876539 Change-Id: If822837f4958434372ef0cb40799aec32ec7cd37 Reviewed-on: https://chromium-review.googlesource.com/1187003 Commit-Queue: agrieve <agrieve@chromium.org> Reviewed-by: John Budorick <jbudorick@chromium.org> Cr-Commit-Position: refs/heads/master@{#585887} [modify] https://crrev.com/bd3c0e676955a999600b966e2c02bec00dbacabf/DEPS [modify] https://crrev.com/bd3c0e676955a999600b966e2c02bec00dbacabf/build/android/pylib/utils/proguard.py [modify] https://crrev.com/bd3c0e676955a999600b966e2c02bec00dbacabf/third_party/.gitignore [modify] https://crrev.com/bd3c0e676955a999600b966e2c02bec00dbacabf/third_party/proguard/BUILD.gn [modify] https://crrev.com/bd3c0e676955a999600b966e2c02bec00dbacabf/third_party/proguard/README.chromium [add] https://crrev.com/bd3c0e676955a999600b966e2c02bec00dbacabf/third_party/proguard/cipd.yaml [delete] https://crrev.com/1f8eb50a729b9770ea88150846eb5d03ed2c254f/third_party/proguard/lib/proguard.jar [delete] https://crrev.com/1f8eb50a729b9770ea88150846eb5d03ed2c254f/third_party/proguard/lib/retrace.jar
,
Aug 24
,
Aug 24
We should be fine to re-enable deobfuscation now, but might be wise to wait until monday :)
,
Aug 24
,
Aug 24
,
Aug 24
#46: I'm going to look at 877149 before doing so.
,
Aug 24
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/78561f5b9dca2d5e742a43ddf0f553eaf4a76c70 commit 78561f5b9dca2d5e742a43ddf0f553eaf4a76c70 Author: agrieve <agrieve@chromium.org> Date: Fri Aug 24 19:55:43 2018 Revert "Android: Update version of retrace.jar to 6.0.3" This reverts commit bd3c0e676955a999600b966e2c02bec00dbacabf. Reason for revert: Broke angle_perftests Original change's description: > Android: Update version of retrace.jar to 6.0.3 > > The existing version was found to infinite loop at times. > Also moves the jars to CIPD > > NOTRY=true # windows bot failing > > Bug: 876539 > Change-Id: If822837f4958434372ef0cb40799aec32ec7cd37 > Reviewed-on: https://chromium-review.googlesource.com/1187003 > Commit-Queue: agrieve <agrieve@chromium.org> > Reviewed-by: John Budorick <jbudorick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#585887} TBR=agrieve@chromium.org,jbudorick@chromium.org Change-Id: Icd2cf44c9e48390f6b13641d6fac97fd0f75df5d No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: 876539 , 877619 Reviewed-on: https://chromium-review.googlesource.com/1188866 Reviewed-by: agrieve <agrieve@chromium.org> Commit-Queue: agrieve <agrieve@chromium.org> Cr-Commit-Position: refs/heads/master@{#585955} [modify] https://crrev.com/78561f5b9dca2d5e742a43ddf0f553eaf4a76c70/DEPS [modify] https://crrev.com/78561f5b9dca2d5e742a43ddf0f553eaf4a76c70/build/android/pylib/utils/proguard.py [modify] https://crrev.com/78561f5b9dca2d5e742a43ddf0f553eaf4a76c70/third_party/.gitignore [modify] https://crrev.com/78561f5b9dca2d5e742a43ddf0f553eaf4a76c70/third_party/proguard/BUILD.gn [modify] https://crrev.com/78561f5b9dca2d5e742a43ddf0f553eaf4a76c70/third_party/proguard/README.chromium [delete] https://crrev.com/daeda01281efc0810df252157bcf623f1faac38c/third_party/proguard/cipd.yaml [add] https://crrev.com/78561f5b9dca2d5e742a43ddf0f553eaf4a76c70/third_party/proguard/lib/proguard.jar [add] https://crrev.com/78561f5b9dca2d5e742a43ddf0f553eaf4a76c70/third_party/proguard/lib/retrace.jar
,
Aug 27
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/40dece27d6b58fb916aa8d27aadaa5def856584f commit 40dece27d6b58fb916aa8d27aadaa5def856584f Author: Andrew Grieve <agrieve@chromium.org> Date: Mon Aug 27 17:59:40 2018 Reland "Android: Update version of retrace.jar to 6.0.3" Reverted in: 78561f5b9dca2d5e742a43ddf0f553eaf4a76c70 Reason for reland: * Should now work with swarming * Contains fix for angle_perftest (ran locally) The existing version was found to infinite loop at times. Also moves the jars to CIPD Bug: 876539 , 877619 Change-Id: I9564c9b5dd6339abd1ded62d9bba98f9692a601d Reviewed-on: https://chromium-review.googlesource.com/1188601 Reviewed-by: John Budorick <jbudorick@chromium.org> Commit-Queue: agrieve <agrieve@chromium.org> Cr-Commit-Position: refs/heads/master@{#586312} [modify] https://crrev.com/40dece27d6b58fb916aa8d27aadaa5def856584f/DEPS [modify] https://crrev.com/40dece27d6b58fb916aa8d27aadaa5def856584f/build/android/BUILD.gn [modify] https://crrev.com/40dece27d6b58fb916aa8d27aadaa5def856584f/build/android/pylib/constants/__init__.py [modify] https://crrev.com/40dece27d6b58fb916aa8d27aadaa5def856584f/build/android/pylib/utils/device_dependencies.py [modify] https://crrev.com/40dece27d6b58fb916aa8d27aadaa5def856584f/build/android/pylib/utils/proguard.py [modify] https://crrev.com/40dece27d6b58fb916aa8d27aadaa5def856584f/third_party/.gitignore [modify] https://crrev.com/40dece27d6b58fb916aa8d27aadaa5def856584f/third_party/proguard/BUILD.gn [modify] https://crrev.com/40dece27d6b58fb916aa8d27aadaa5def856584f/third_party/proguard/README.chromium [add] https://crrev.com/40dece27d6b58fb916aa8d27aadaa5def856584f/third_party/proguard/cipd.yaml [delete] https://crrev.com/25113733c29967022d59118621aabe491a7bcc13/third_party/proguard/lib/proguard.jar [delete] https://crrev.com/25113733c29967022d59118621aabe491a7bcc13/third_party/proguard/lib/retrace.jar
,
Aug 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e5e16ac5fd5b173293001345d6ae5fd139b1916f commit e5e16ac5fd5b173293001345d6ae5fd139b1916f Author: agrieve <agrieve@chromium.org> Date: Thu Aug 30 19:32:42 2018 Revert "android: disable deobfuscation in tests." This reverts commit b81f63ce2e0725921c81fb977d33fe5b95e951b5. Reason for revert: retrace bug now fixed Original change's description: > android: disable deobfuscation in tests. > > Deobfuscation appears to be hanging in ways that cause it to peg > bots' CPUs and kill test runs. This CL temporarily disables it as > a mitigation. > > Bug: 876539 > Change-Id: I6dced1a4c80e630bb701a17eaa8322450661adc5 > Reviewed-on: https://chromium-review.googlesource.com/1185294 > Reviewed-by: Ben Pastene <bpastene@chromium.org> > Commit-Queue: John Budorick <jbudorick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#585190} Bug: 876539 Change-Id: If6c19b7345e769d51d1580980aca8e3967319a97 Reviewed-on: https://chromium-review.googlesource.com/1195432 Reviewed-by: Ben Pastene <bpastene@chromium.org> Reviewed-by: agrieve <agrieve@chromium.org> Commit-Queue: agrieve <agrieve@chromium.org> Cr-Commit-Position: refs/heads/master@{#587707} [modify] https://crrev.com/e5e16ac5fd5b173293001345d6ae5fd139b1916f/build/config/android/internal_rules.gni
,
Aug 31
Looks like Kitkat bots feel healthy, removing sheriff-android label.
,
Aug 31
|
||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||
Comment 1 by s...@chromium.org
, Aug 21