New issue
Advanced search Search tips

Issue 598886 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Jan 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug

Blocking:
issue 596760



Sign in to add a comment

base::debug::StackTrace().Print() doesn't print decent stack traces even in mac_strip_release=0 mode

Project Member Reported by esprehn@chromium.org, Mar 29 2016

Issue description

ex.

0   libbase.dylib                       0x0000000101fba183 _ZN4base5debug10StackTraceC1Ev + 19
1   libwebcore_shared.dylib             0x000000010ae52631 _ZN5blink7Element9innerTextEv + 49
2   libwebcore_shared.dylib             0x000000010a796310 _ZN5blink21HTMLElementV8InternalL32innerTextAttributeGetterCallbackERKN2v820FunctionCallbackInfoINS1_5ValueEEE + 80
3   ???                                 0x0000340eb7111850 0x0 + 57237805537360
4   ???                                 0x0000340eb754e037 0x0 + 57237809979447
5   ???                                 0x0000340eb75644d0 0x0 + 57237810070736
6   ???                                 0x0000340eb737226e 0x0 + 57237808030318


compared to the output of the BACKTRACE() macro that webkit used to have, the debug one is missing most of the symbols in release mode (even with mac_strip_release=0).

Note that this used to have better output a while ago, and ReportCrash does have decent output:

Thread 0 Crashed:: CrRendererMain  Dispatch queue: com.apple.main-thread
0   libwebcore_shared.dylib       	0x00000001115306b8 blink::Element::innerText() + 136 (Element.cpp:2696)
1   libwebcore_shared.dylib       	0x0000000110e746e0 blink::HTMLElementV8Internal::innerTextAttributeGetterCallback(v8::FunctionCallbackInfo<v8::Value> const&) + 80 (v8.h:7820)
2   libv8.dylib                   	0x000000010ffd275d v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) + 365 (api-arguments.h:61)
3   libv8.dylib                   	0x0000000110002db2 v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::(anonymous namespace)::BuiltinArguments<(v8::internal::BuiltinExtraArguments)1>) + 898 (isolate-inl.h:60)
4   libv8.dylib                   	0x00000001100029c9 v8::internal::Builtins::InvokeApiFunction(v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*) + 409 (objects-inl.h:7667)
5   libv8.dylib                   	0x0000000110372409 v8::internal::Object::GetPropertyWithAccessor(v8::internal::LookupIterator*) + 473 (isolate-inl.h:42)
6   libv8.dylib                   	0x00000001103719ad v8::internal::Object::GetProperty(v8::internal::LookupIterator*) + 221 (objects.cc:738)
7   libv8.dylib                   	0x000000011031aa53 v8::internal::LoadIC::Load(v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Name>) + 947 (handles.h:216)
8   libv8.dylib                   	0x00000001103217e8 v8::internal::Runtime_LoadIC_Miss(int, v8::internal::Object**, v8::internal::Isolate*) + 2616 (handles.h:216)
9   ???                           	0x000022a36c206647 0 + 38085289076295
10  ???                           	0x000022a36c379817 0 + 38085290596375
11  ???                           	0x000022a36c3788fc 0 + 38085290592508
12  ???                           	0x000022a36c374ece 0 + 38085290577614
13  ???                           	0x000022a36c209815 0 + 38085289089045
14  ???                           	0x000022a36c37835c 0 + 38085290591068
15  ???                           	0x000022a36c36e2fc 0 + 38085290550012
16  ???                           	0x000022a36c209815 0 + 38085289089045
17  ???                           	0x000022a36c764987 0 + 38085294705031
18  ???                           	0x000022a36c6fcbef 0 + 38085294279663
19  ???                           	0x000022a36c239583 0 + 38085289284995
20  ???                           	0x000022a36c226a0f 0 + 38085289208335
21  libv8.dylib                   	0x0000000110280990 v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, bool, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*, v8::internal::Handle<v8::internal::Object>) + 400 (execution.cc:97)
22  libv8.dylib                   	0x0000000110280727 v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*) + 455 (execution.cc:165)
23  libv8.dylib                   	0x000000010ffaa6c6 v8::Script::Run(v8::Local<v8::Context>) + 550 (handles.h:216)
24  libwebcore_shared.dylib       	0x0000000110d1df7d blink::V8ScriptRunner::runCompiledScript(v8::Isolate*, v8::Local<v8::Script>, blink::ExecutionContext*) + 765 (V8ScriptRunner.cpp:417)
25  libwebcore_shared.dylib       	0x0000000110ce5e18 blink::ScriptController::executeScriptAndReturnValue(v8::Local<v8::Context>, blink::ScriptSourceCode const&, blink::AccessControlStatus, double*) + 680 (ScriptController.cpp:190)
26  libwebcore_shared.dylib       	0x0000000110ce7625 blink::ScriptController::evaluateScriptInMainWorld(blink::ScriptSourceCode const&, blink::AccessControlStatus, blink::ScriptController::ExecuteScriptPolicy, double*) + 261 (ScriptController.cpp:570)
27  libwebcore_shared.dylib       	0x0000000110ce7776 blink::ScriptController::executeScriptInMainWorld(blink::ScriptSourceCode const&, blink::AccessControlStatus, double*) + 70 (ScriptController.cpp:543)
28  libwebcore_shared.dylib       	0x0000000111574641 blink::ScriptLoader::executeScript(blink::ScriptSourceCode const&, double*) + 2433 (Handle.h:772)
29  libwebcore_shared.dylib       	0x0000000111572e03 blink::ScriptLoader::prepareScript(WTF::TextPosition const&, blink::ScriptLoader::LegacyTypeSupport) + 1299 (ScriptLoader.cpp:275)
30  libwebcore_shared.dylib       	0x0000000111758d9b blink::HTMLScriptRunner::runScript(blink::Element*, WTF::TextPosition const&) + 331 (ScriptLoader.h:67)
31  libwebcore_shared.dylib       	0x0000000111758b43 blink::HTMLScriptRunner::execute(WTF::RawPtr<blink::Element>, WTF::TextPosition const&) + 371 (Handle.h:823)
32  libwebcore_shared.dylib       	0x0000000111747516 blink::HTMLDocumentParser::processParsedChunkFromBackgroundParser(WTF::PassOwnPtr<blink::HTMLDocumentParser::ParsedChunk>) + 1174 (PassOwnPtr.h:78)
33  libwebcore_shared.dylib       	0x000000011174638f blink::HTMLDocumentParser::pumpPendingSpeculations() + 639 (HTMLDocumentParser.cpp:564)

 
Summary: base::debug::StackTrace().Print() doesn't print decent stack traces even in mac_strip_release=0 mode (was: base::debug::StackTrace().Print() doesn't print decent stack traces even in release)

Comment 2 by danakj@chromium.org, Mar 29 2016

Cc: mark@chromium.org thestig@chromium.org
> Note that this used to have better output a while ago

Got an idea when? Can you bisect?

I don't know of anyone changing this.
I can try doing that later, in general base::debug::StackTrace is missing a bunch of features that blink's BACKTRACE had that made debugging easy. For example it prints the libraries, it doesn't let you limit the number of lines easily, it doesn't unmangle. I think they crashed in different ways.

tkent@ recently removed BACKTRACE() from WTF, I think maybe we should add it back for debugging.

Comment 4 by danakj@chromium.org, Mar 29 2016

Let's improve the base one, we should have good sample code from what was removed then :)

Comment 5 by danakj@chromium.org, Mar 29 2016

Cc: scottmg@chromium.org
Note that it's not clear to me that base::debug::StackTrace() actually changed. It think OS X might be different post 10.11 or something. Also WTF and base collected the stack trace in two different ways.

Having a base::debug::StackTrace with the same easy features as BACKTRACE() and pretty output would be super useful. :)

Comment 7 by tkent@chromium.org, Jun 23 2016

Components: -Blink>Architecture Blink>Internals
Renaming Blink>Architecture to Blink>Internals

Comment 8 by w...@chromium.org, Jan 24 2017

Owner: w...@chromium.org
Status: Started (was: Untriaged)
I have a patch in progress that adds support for limiting number of frames in trace printout, and am working on fixing name demangling under Mac.

Comment 9 by w...@chromium.org, Jan 24 2017

Blocking: 596760
Project Member

Comment 10 by bugdroid1@chromium.org, Jan 26 2017

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

commit bf51bcfadc991bbf00161d8a28fa7fdad74b8222
Author: wez <wez@chromium.org>
Date: Thu Jan 26 19:40:26 2017

Remove outdated __GLIBCXX_ checks in base::StackTrace for POSIX.

This fixes symbol name unmangling under Mac OS X, where we have switched
from building against libstdc++, which defines __GLIBCXX__, to libc++,
which does not. All we actually care about is that the C++ library
provides the abi::__cxa_demangle() API, which both libraries do.

BUG= 598886 , 596760 

Review-Url: https://codereview.chromium.org/2651893002
Cr-Commit-Position: refs/heads/master@{#446398}

[modify] https://crrev.com/bf51bcfadc991bbf00161d8a28fa7fdad74b8222/base/debug/stack_trace_posix.cc

Comment 11 by w...@chromium.org, Jan 26 2017

Status: Fixed (was: Started)

Comment 12 by w...@chromium.org, Jan 26 2017

Labels: M-58

Sign in to add a comment