New issue
Advanced search Search tips

Issue 700543 link

Starred by 3 users

Issue metadata

Status: Assigned
Owner:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

Blocked on:
issue 699153
issue 699062



Sign in to add a comment

Symbols on mac/asan don't work

Project Member Reported by thakis@chromium.org, Mar 10 2017

Issue description

Back in the gyp days, the mac/asan bots built dSYMs and sent them to swarming, where the dSYMs were used for providing symbols.

This is currently broken in several ways.

1. dSYMs are getting built but aren't in data_deps and hence aren't sent to swarming slaves.

2. In gn, the dSYM path changed (bug 699153) and we pass the wrong path to llvm-symbolizer (possible untested fix https://codereview.chromium.org/2742693004/)


The main effect of this is that stacks on e.g. https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Ftryserver.chromium.mac%2Fmac_chromium_asan_rel_ng%2F4499%2F%2B%2Frecipes%2Fsteps%2Fcontent_browsertests__with_patch_%2F0%2Fstdout don't have line numbers but ?? marks:

==11935==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000115abbb70 bp 0x7fff54d80a30 sp 0x7fff54d80a30 T0)
==11935==The signal is caused by a WRITE memory access.
==11935==Hint: address points to the zero page.
    #0 0x115abbb6f in content::(anonymous namespace)::CrashIntentionally() ??:0:0
    #1 0x115aabf99 in content::RenderFrameImpl::PrepareRenderViewForNavigation(GURL const&, content::RequestNavigationParams const&) ??:0:0
    #2 0x115a66eeb in content::RenderFrameImpl::NavigateInternal(content::CommonNavigationParams const&, content::StartNavigationParams const&, content::RequestNavigationParams const&, std::__1::unique_ptr<content::StreamOverrideParameters, std::__1::default_delete<content::StreamOverrideParameters> >) ??:0:0
    #3 0x115a40dda in content::RenderFrameImpl::OnNavigate(content::CommonNavigationParams const&, content::StartNavigationParams const&, content::RequestNavigationParams const&) ??:0:0
    #4 0x115a4088b in bool IPC::MessageT<FrameMsg_Navigate_Meta, std::__1::tuple<content::CommonNavigationParams, content::StartNavigationParams, content::RequestNavigationParams>, void>::Dispatch<content::RenderFrameImpl, content::RenderFrameImpl, void, void (content::RenderFrameImpl::*)(content::CommonNavigationParams const&, content::StartNavigationParams const&, content::RequestNavigationParams const&)>(IPC::Message const*, content::RenderFrameImpl*, content::RenderFrameImpl*, void*, void (content::RenderFrameImpl::*)(content::CommonNavigationParams const&, content::StartNavigationParams const&, content::RequestNavigationParams const&)) ??:0:0
    #5 0x115a3ad42 in content::RenderFrameImpl::OnMessageReceived(IPC::Message const&) ??:0:0
 

Comment 1 by thakis@chromium.org, Mar 10 2017

(bug 415179 is somewhat related)

Comment 2 by thakis@chromium.org, Mar 10 2017

Also, glider pointed out in https://bugs.chromium.org/p/chromium/issues/detail?id=686113#c10 that it looks like we're going down the atos path instead of the llvm-symbolizer path for unknown reasons (maybe just because the dsym doesn't exist?)

Comment 3 by rsesek@chromium.org, Mar 13 2017

#1 is interesting because the toolchain should list the dSYMs as outputs when they are enabled: https://cs.chromium.org/chromium/src/build/toolchain/mac/BUILD.gn?dr&l=178
Labels: -Pri-3 M-59 Pri-2
Owner: rsesek@chromium.org
Status: Assigned (was: Untriaged)
This seems like something we should fix. Assigning to rsesek@, most experienced of gn conversionteers.

Sign in to add a comment