Crazy Stack Trace On Android

Brian White

unread,

May 17, 2017, 4:33:12 PM5/17/17

to chromium-dev

I could use some help from an Android/Clank expert as I work mostly on Windows.

I'm investigating...

https://bugs.chromium.org/p/chromium/issues/detail?id=722800

... and am having trouble figuring out what is going on.

These crashes occur on all platforms but Android makes up about 97% of them.

https://crash.corp.google.com/browse?q=custom_data.ChromeCrashProto.magic_signature_1.name%3D%27base%3A%3AHashMetricName%27%20AND%20custom_data.ChromeCrashProto.malware_verdict%3Dfalse&ignore_case=false&enable_rewrite=false&omit_field_name=&omit_field_value=&omit_field_opt=#-property-selector,samplereports:15,-component,-filepath,-author,-changelist,-magicsignature2,crashreason,-clientid

Digging into some Android SIGSEGV exceptions, the most common, the stack frequently looks like this:

0x63c9e76b (libchrome.so -string:2594 ) std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> >::append(char const*, unsigned int)

0x63ca4d6b (libchrome.so -stringprintf.cc:66 ) StringAppendVT<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > >

0x00000000

0x68273752 (BrowserMetrics-active.pma + 0x00000752 )

0x682736f6 (BrowserMetrics-active.pma + 0x000006f6 )

0x63ca7ff5 (libchrome.so -metrics_hashes.cc:27 ) base::HashMetricName(base::BasicStringPiece<std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > >)

0x63cd7f41 (libchrome.so -histogram.cc:528 ) base::Histogram::Histogram(std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > const&, int, int, base::BucketRanges const*, int*, int*, unsigned int, base::HistogramSamples::Metadata*, base::HistogramSamples::Metadata*)

0x63cdd3f5 (libchrome.so -histogram.cc:864 ) base::BooleanHistogram::PersistentCreate(std::__ndk1::basic_string<char, std::__ndk1::char_traits<char>, std::__ndk1::allocator<char> > const&, base::BucketRanges const*, int*, int*, base::HistogramSamples::Metadata*, base::HistogramSamples::Metadata*)

0x63cd7d55 (libchrome.so -persistent_histogram_allocator.cc:644 ) base::PersistentHistogramAllocator::CreateHistogram(base::PersistentHistogramAllocator::PersistentHistogramData*)

0x66b0c68e

0x63ca9641 (libchrome.so -histogram.cc:431 ) base::Histogram::AddCount(int, int)

0x63ca7971 (libchrome.so -histogram.cc:221 ) base::Histogram::Factory::Build()

Now this is strange for two reasons:

It's executing code from the mapped "BrowserMetrics-active.pma" data file.
base::Histogram::AddCount() does not create a histogram.

It's possible that #1 is just an artifact of a bad stack from #2 but I need an expert to help me figure out what is real and what is not.

Anyone?

Brian
bcw...@google.com
-----------------------------------------------------------------------------------------
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

Bo Liu

unread,

May 17, 2017, 4:45:58 PM5/17/17

to bcw...@google.com, chromium-dev, Torne (Richard Coles), yfri...@chromium.org, di...@chromium.org

All crashes are on kitkat. Looks like legacy/crazy linker problem? +torne/yfriedman/digit

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAB8qB%2BuTn6-X7WOkiUnUn%3DuHPszGFrc8j-jyC%3Dp%2Bc-ZrELnCEw%40mail.gmail.com.

Mark Mentovai

unread,

May 17, 2017, 4:47:10 PM5/17/17

to Brian White, chromium-dev

There’s a third signal that the stack is untrustworthy: the apparent text at 0 in the call stack.

I’m more inclined to believe that this is a failure to recover something’s caller correctly, so the stackwalker falls back to stack scanning and you get a couple of bogus frames in there before things recover somewhat. You didn’t give a link to the crash report you pasted, but I’d bet that if you took a closer look, you’d find frames “guessed” by stack scanning (they’ll appear in gray on the crash server UI) along with a low value for “stack quality” and probably a yellow warning triangle (⚠️).

At and beyond the first caller recovered by stack scanning, the entire rest of the stack may just be garbage.

David Turner

unread,

May 18, 2017, 5:47:18 AM5/18/17

to Mark Mentovai, Brian White, chromium-dev

On Wed, May 17, 2017 at 10:46 PM, Mark Mentovai <ma...@chromium.org> wrote:

There’s a third signal that the stack is untrustworthy: the apparent text at 0 in the call stack.

I’m more inclined to believe that this is a failure to recover something’s caller correctly, so the stackwalker falls back to stack scanning and you get a couple of bogus frames in there before things recover somewhat. You didn’t give a link to the crash report you pasted, but I’d bet that if you took a closer look, you’d find frames “guessed” by stack scanning (they’ll appear in gray on the crash server UI) along with a low value for “stack quality” and probably a yellow warning triangle (⚠️).

At and beyond the first caller recovered by stack scanning, the entire rest of the stack may just be garbage.

Mark is right, here's one of the stack crashes that shows the AddCount call in grey :-/

https://crash.corp.google.com/browse?q=custom_data.ChromeCrashProto.magic_signature_1.name%3D%27base%3A%3AHashMetricName%27%20AND%20custom_data.ChromeCrashProto.malware_verdict%3Dfalse&ignore_case=false&enable_rewrite=false&omit_field_name=&omit_field_value=&omit_field_opt=&stbtiq=&reportid=45a1ed19a8000000&index=1

A CFI entry with address 0 definitely means something's wrong with the stack trace anyway.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAHk1GDyR_k4MGTdiLu9adML_znZwY5HBkZo7DR5odtXD%2Bu6v-Q%40mail.gmail.com.

Brian White

unread,

May 18, 2017, 7:24:26 AM5/18/17

to David Turner, Mark Mentovai, chromium-dev

There’s a third signal that the stack is untrustworthy: the apparent text at 0 in the call stack.

I’m more inclined to believe that this is a failure to recover something’s caller correctly, so the stackwalker falls back to stack scanning and you get a couple of bogus frames in there before things recover somewhat. You didn’t give a link to the crash report you pasted, but I’d bet that if you took a closer look, you’d find frames “guessed” by stack scanning (they’ll appear in gray on the crash server UI) along with a low value for “stack quality” and probably a yellow warning triangle (⚠️).

At and beyond the first caller recovered by stack scanning, the entire rest of the stack may just be garbage.

Mark is right, here's one of the stack crashes that shows the AddCount call in grey :-/

https://crash.corp.google.com/browse?q=custom_data.ChromeCrashProto.magic_signature_1.name%3D%27base%3A%3AHashMetricName%27%20AND%20custom_data.ChromeCrashProto.malware_verdict%3Dfalse&ignore_case=false&enable_rewrite=false&omit_field_name=&omit_field_value=&omit_field_opt=&stbtiq=&reportid=45a1ed19a8000000&index=1

The call to AddCount might be valid given that it is called (through a few other methods) just before the line indicated in following Build() call. But it shouldn't be creating another histogram so everything above it is suspect.

-- Brian

Reply all

Reply to author

Forward