New issue
Advanced search Search tips

Issue 889937 link

Starred by 1 user
Status: Verified
Owner:
torne@chromium.org
Closed: Sep 27
Cc:
benmason@chromium.org
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug



Sign in to add a comment

Breakpad symbols not usable for 32-bit libmonochrome.so inside 64-bit Monochrome.apk

Project Member Reported by torne@chromium.org, Sep 27 
The 32-bit libmonochrome.so built by the 64-bit builder for Monochrome doesn't generate usable breakpad symbols, leading to bad stack decodings for all crashes happening in monochrome or 32-bit webviews on 64-bit devices.

This affects all M71+ builds as that's when building the combined APK on the 64-bit builder (instead of merging the two APKs) was enabled.

This is due to  issue 744956 : breakpad can't parse DWARF4 correctly for arm32, but the workaround for that issue only applies when target_cpu="arm" - this should be current_cpu="arm" instead to make it apply to the secondary toolchain build.

Comment 1 by torne@chromium.org, Sep 27 

We may need to check for other uses of target_cpu that should actually be current_cpu as well - we weren't previously actually shipping the 32-bit binary from the 64-bit build so it didn't matter as much whether it was exactly correct :(
Project Member

Comment 2 by bugdroid1@chromium.org, Sep 27 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/92013e54ab1d7a2e1bde349f36ad1f80f32f3112

commit 92013e54ab1d7a2e1bde349f36ad1f80f32f3112
Author: Torne (Richard Coles) <torne@google.com>
Date: Thu Sep 27 18:22:32 2018

Fix compiler flags incorrectly checking target_cpu.

Various GN conditions check target_cpu when deciding which compiler
flags to apply; they should be checking current_cpu instead so that
builds with more than one toolchain use the correct flags for each
toolchain. This was causing the DWARF version workaround for
 crbug.com/744956  to not be applied on the 64-bit build when using the
32-bit toolchain.

Bug:  744956 ,  889937 
Change-Id: Id2f4ecafd762e36ed3593fb45f6a6062bf8f6326
Reviewed-on: https://chromium-review.googlesource.com/1249393
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Richard Coles <torne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#594791}
[modify] https://crrev.com/92013e54ab1d7a2e1bde349f36ad1f80f32f3112/build/config/compiler/BUILD.gn

Comment 3 by torne@chromium.org, Sep 27

Status: Fixed (was: Started)
Need to verify this once we push out a canary/dev build including the change, by checking if the crash stacks from 64-bit devices have good quality again.

Comment 4 by torne@chromium.org, Oct 1

Status: Verified (was: Fixed)
No bad unwindings (for legitimate cases) on canary, so considering this fixed.
►

Sign in to add a comment