Symbolicating Chrome OS stack traces

[Sunny Sachanandani]

Hi,

I'm building Chrome for Chrome OS using the simple chrome workflow. I can log stack traces using base::debug::StackTrace but those aren't being symbolicated on device even if I deploy chrome without stripping symbols (--nostrip) and symbol_level = 2. The minidump_stackwalk tool fails because I don't have a minidump, just a stack trace with a bunch of addresses. Is there a tool that can symbolicate these stack traces?

Thanks!

- Sunny

[Sunny Sachanandani]

A few folks gave some helpful advice off channel. I tried producing non-stripped binaries both with --nostrip (non rootfs install with mount) and by stripping blink symbols using --strip-flags '-w -K "!*WebCore*"' but neither of those worked. Someone suggested --no-sandbox but that doesn't allow me to start chrome at all. I also tried to deploy a debug build but that seemed to take forever.

In the end, I symbolized the addresses manually on my workstation by using addr2line -e <binary> -C -f <stack trace address - base address> where base address can be found from /proc/<chrome pid>/maps in the chrome text segment marked "r-xp".

[Sunny Sachanandani]

I also verified that I can symbolize addresses using the chrome binary I deployed to the device so it's surprising that base::debug::StackTrace can't symbolize it.

[Satoru Takabayashi]

FWIW, it worked for me with 'daisy' board:

1) Add a code snippet like below in the code, and build the chrome binary per simplechrome workflow

%  LOG(ERROR) << "@@ " << base::debug::StackTrace().ToString();

2) deploy the binary with --strip-flags=-S option:

% deploy_chrome --build-dir=out_${SDK_BOARD}/Release --to=<ip> --strip-flags=-S

3) Check the log on the device:

% grep -A15 '@@' ~/log/chrome

[17739:17971:0206/133008.461503:ERROR:url_request_file_dir_job.cc(141)] @@ #0 0x0000b2389bd2 base::debug::StackTrace::StackTrace()

#1 0x0000b238969a base::debug::StackTrace::StackTrace()

#2 0x0000b2588250 net::URLRequestFileDirJob::OnListFile()

#3 0x0000b26025b6 net::DirectoryLister::Core::DoneOnOriginThread()

#4 0x0000b260273e _ZN4base8internal7InvokerINS0_9BindStateIMN3net15DirectoryLister4CoreEKFvSt10unique_ptrISt6vectorINS4_19DirectoryListerDataESaIS8_EESt14default_deleteISA_EEiEJ13scoped_refptrIS5_ENS0_13PassedWrapperISD_EENS3_5ErrorEEEEFvvEE3RunEPNS0_13BindStateBaseE

#5 0x0000b2404d6a base::debug::TaskAnnotator::RunTask()

#6 0x0000b23a3f72 base::MessageLoop::RunTask()

#7 0x0000b23a427a base::MessageLoop::DeferOrRunPendingTask()

#8 0x0000b23a5706 base::MessageLoop::DoWork()

#9 0x0000b23a5bc2 base::MessagePumpLibevent::Run()

#10 0x0000b23a38bc base::MessageLoop::RunHandler()

#11 0x0000b23c3150 base::RunLoop::Run()

#12 0x0000b0f44ef6 content::BrowserThreadImpl::IOThreadRun()

#13 0x0000b0f45282 content::BrowserThreadImpl::Run()

#14 0x0000b23df4c2 base::Thread::ThreadMain()

#15 0x0000b23dbafe base::(anonymous namespace)::ThreadFunc()

Demangler needs to be updated to handle #4 but that's a separate issue.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Xingyu]

I ran into the same problem a while back. 

Can someone please update the Simple Chrome doc to reflect this?

[Mike Frysinger]

the simple chrome doc is on dev.chromium.org which is a wiki which anyone with an @chromium.org address can update

-mike

--

[Dongseong Hwang]

stack trace didn't work in some Intel platform before, but https://chromium-review.googlesource.com/754232 fixed it.