Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
15738020:
Roll Clang 179138:182481. (Closed)
|
Created:
7 years, 7 months ago by hans Modified:
7 years, 6 months ago Reviewers:
Alexander Potapenko, (unused - use chromium), commit-bot: I haz the power, Nico, _com_google_glider, eugenis CC:
chromium-reviews, eugenis+clang_chromium.org, glider+clang_chromium.org, dmikurube+clang_chromium.org, ukai+watch_chromium.org Base URL:
svn://svn.chromium.org/chrome/trunk/src Visibility:
Public. |
DescriptionRoll Clang 179138:182481.
BUG=241737
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=202554
Patch Set 1 #
Messages
Total messages: 17 (0 generated)
+thakis for roll review +eugenis for update.sh review New roll attempt. Yesterday we tried to roll to 182465, but it turned out the pushed Linux binary was broken (bad RPATH, it contained a /home directory). Rather than trying to re-push the binaries, I wanted to just bump to the next revision to tell them apart. Unfortunately that revision broke ASan on Android and Mac. These were fixed in 182479 and 182481 respectively, so let's roll to the later :) The other changes in between look harmless. I also used a relative path for the Android tool chain when building the ASan runtime this time. I don't know if it really makes a difference, but that's how we did it before so maybe it's safer. I fixed the path to work both when we're running as "gclient runhooks" and "update.sh"; previously I think it only worked by accident.
On 2013/05/24 10:43:56, hans wrote: > +thakis for roll review > +eugenis for update.sh review LGTM > > New roll attempt. > > Yesterday we tried to roll to 182465, but it turned out the pushed Linux binary > was broken (bad RPATH, it contained a /home directory). > > Rather than trying to re-push the binaries, I wanted to just bump to the next > revision to tell them apart. Unfortunately that revision broke ASan on Android > and Mac. These were fixed in 182479 and 182481 respectively, so let's roll to > the later :) The other changes in between look harmless. > > I also used a relative path for the Android tool chain when building the ASan > runtime this time. I don't know if it really makes a difference, but that's how > we did it before so maybe it's safer. I fixed the path to work both when we're > running as "gclient runhooks" and "update.sh"; previously I think it only worked > by accident. I don't think absolute vs relative path affects build products, and absolute path seems less fragile. Either way is OK.
Any progress with this?
On 2013/05/28 07:01:26, Alexander Potapenko wrote: > Any progress with this? Yesterday was a public holiday here so I haven't looked at it since Friday. I'd like to figure out if the test failures on the mac* trybots are transient or related to this patch. Hopefully they were transient and we're good to go, let's see.
On 2013/05/28 09:12:44, hans wrote: > I'd like to figure out if the test failures on the mac* trybots are transient or > related to this patch. Hopefully they were transient and we're good to go, let's > see. Bots look good. Taking this to the cq.
No LGTM from a valid reviewer yet. Only full committers are accepted. Even if an LGTM may have been provided, it was from a non-committer or a lowly provisional committer, _not_ a full super star committer. See http://www.chromium.org/getting-involved/become-a-committer Note that this has nothing to do with OWNERS files.
LGTM
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/hans@chromium.org/15738020/1
Message was sent while issue was closed.
Change committed as 202554
Message was sent while issue was closed.
lgtm, but we shouldn't make a habit of rolling to non-internally blessed revisions. If asan makes a roll fail (as it's wont to :-( ), we should generally just wait for the next opportunity. glider: asan was broken on android and mac, maybe these platforms should have asan canaries too?
It should be fairly easy to make an ASan Mac canary bot. However I'm not sure about the Android (Evgeniy?) On Tue, May 28, 2013 at 11:47 PM, <thakis@chromium.org> wrote: > lgtm, but we shouldn't make a habit of rolling to non-internally blessed > revisions. If asan makes a roll fail (as it's wont to :-( ), we should > generally > just wait for the next opportunity. > > glider: asan was broken on android and mac, maybe these platforms should > have > asan canaries too? > > https://chromiumcodereview.appspot.com/15738020/ -- Alexander Potapenko Software Engineer Google Moscow
We could easily setup a slave with an android device. But there is only one asan/android on the chromium.fyi waterfall, and has not been fully green for quite some time. http://build.chromium.org/p/chromium.fyi/builders/Android%20Asan%20Builder%20... OK, most of the tests on that bot pass, we could run those on the canary bot. On Wed, May 29, 2013 at 12:01 AM, Alexander Potapenko <glider@google.com> wrote: > It should be fairly easy to make an ASan Mac canary bot. However I'm > not sure about the Android (Evgeniy?) > > On Tue, May 28, 2013 at 11:47 PM, <thakis@chromium.org> wrote: >> lgtm, but we shouldn't make a habit of rolling to non-internally blessed >> revisions. If asan makes a roll fail (as it's wont to :-( ), we should >> generally >> just wait for the next opportunity. >> >> glider: asan was broken on android and mac, maybe these platforms should >> have >> asan canaries too? >> >> https://chromiumcodereview.appspot.com/15738020/ > > > > -- > Alexander Potapenko > Software Engineer > Google Moscow
We should probably move Android ASan to the Memory waterfall. On Wed, May 29, 2013 at 12:22 AM, Evgeniy Stepanov <eugenis@chromium.org> wrote: > We could easily setup a slave with an android device. But there is > only one asan/android on the chromium.fyi waterfall, and has not been > fully green for quite some time. > http://build.chromium.org/p/chromium.fyi/builders/Android%20Asan%20Builder%20... > OK, most of the tests on that bot pass, we could run those on the canary bot. > > On Wed, May 29, 2013 at 12:01 AM, Alexander Potapenko <glider@google.com> wrote: >> It should be fairly easy to make an ASan Mac canary bot. However I'm >> not sure about the Android (Evgeniy?) >> >> On Tue, May 28, 2013 at 11:47 PM, <thakis@chromium.org> wrote: >>> lgtm, but we shouldn't make a habit of rolling to non-internally blessed >>> revisions. If asan makes a roll fail (as it's wont to :-( ), we should >>> generally >>> just wait for the next opportunity. >>> >>> glider: asan was broken on android and mac, maybe these platforms should >>> have >>> asan canaries too? >>> >>> https://chromiumcodereview.appspot.com/15738020/ >> >> >> >> -- >> Alexander Potapenko >> Software Engineer >> Google Moscow -- Alexander Potapenko Software Engineer Google Moscow
Message was sent while issue was closed.
On 2013/05/28 20:22:52, eugenis wrote: > We could easily setup a slave with an android device. But there is > only one asan/android on the chromium.fyi waterfall, and has not been > fully green for quite some time. > http://build.chromium.org/p/chromium.fyi/builders/Android%2520Asan%2520Builde... > OK, most of the tests on that bot pass, we could run those on the canary bot. One simple fix that would be very beneficial is if the Linux Asan canary could build the Asan runtime for Android as well (should just require having target_os = ['android'] in the .gclient file). That doesn't require a device, but would have caught most of the issues I was struggling with last week.
On Wed, May 29, 2013 at 2:12 PM, <hans@chromium.org> wrote: > On 2013/05/28 20:22:52, eugenis wrote: >> >> We could easily setup a slave with an android device. But there is >> only one asan/android on the chromium.fyi waterfall, and has not been >> fully green for quite some time. > > > http://build.chromium.org/p/chromium.fyi/builders/Android%2520Asan%2520Builde... > >> OK, most of the tests on that bot pass, we could run those on the canary >> bot. > > > One simple fix that would be very beneficial is if the Linux Asan canary > could > build the Asan runtime for Android as well (should just require having > target_os > = ['android'] in the .gclient file). That doesn't require a device, but > would > have caught most of the issues I was struggling with last week. We've do that already. Here you can find one of the last week's failures: http://racer-z600.msk.corp.google.com:8010/builders/linux-cmake/builds/5513 > > https://chromiumcodereview.appspot.com/15738020/
Message was sent while issue was closed.
On 2013/05/29 10:30:11, eugenis wrote: > On Wed, May 29, 2013 at 2:12 PM, <mailto:hans@chromium.org> wrote: > > One simple fix that would be very beneficial is if the Linux Asan canary > > could > > build the Asan runtime for Android as well (should just require having > > target_os > > = ['android'] in the .gclient file). That doesn't require a device, but > > would > > have caught most of the issues I was struggling with last week. > > We've do that already. > Here you can find one of the last week's failures: > http://racer-z600.msk.corp.google.com:8010/builders/linux-cmake/builds/5513 That's just one of the errors, though :) I was thinking it would be awesome if it built the runtime the same way we do, using Chromium's update.sh script (which doesn't use cmake) and the NDK that chromium uses (which sometimes changes and breaks things).
Right. We don't test autotools build of compiler-rt on android atm. On Wed, May 29, 2013 at 2:53 PM, <hans@chromium.org> wrote: > On 2013/05/29 10:30:11, eugenis wrote: > >> On Wed, May 29, 2013 at 2:12 PM, <mailto:hans@chromium.org> wrote: >> > One simple fix that would be very beneficial is if the Linux Asan canary >> > could >> > build the Asan runtime for Android as well (should just require having >> > target_os >> > = ['android'] in the .gclient file). That doesn't require a device, but >> > would >> > have caught most of the issues I was struggling with last week. > > >> We've do that already. >> Here you can find one of the last week's failures: >> >> http://racer-z600.msk.corp.google.com:8010/builders/linux-cmake/builds/5513 > > > That's just one of the errors, though :) > > I was thinking it would be awesome if it built the runtime the same way we > do, > using Chromium's update.sh script (which doesn't use cmake) and the NDK that > chromium uses (which sometimes changes and breaks things). > > https://chromiumcodereview.appspot.com/15738020/ |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
