This stack trace looks like total garbage.

AppInfoPermissionsPanel::CreatePermissionsList has no reason to call into ffmpeg, which has no reason to call into BoringSSL. Whether StackedTabStripLayout has a reason to call into AppInfoPermissionPanel I have no idea. Having Safe Browsing call into that mess certainly doesn't make sense, though it could just be aggressive deduping by the linker. Also having a bunch of _inits on the stack is weird.

Then we have cloud_devices::printer::Media::MatchBySize calling into TokenLoadingJob::RespondOnOriginatingThread which can't happen since the latter is only called via PostTaskAndReply.

On top of that, url::ResolveRelative is calling into all of that??


How did you trigger this?

There is no extact repro steps but the whole browser crashed and there were bunch of crashes and this was one of them 

Which were the other crashes? This report really isn't actionable since the entire stack is pretty much garbage.

Crash ID 6716cb9c00000000 (Chrome)

Automatically reported Friday, May 27, 2016 at 2:40:44 PM

Provide additional details

Crash ID 75e1eb1a00000000 (Chrome)

Automatically reported Friday, May 27, 2016 at 2:40:41 PM

Provide additional details

Crash ID 270bcb9c00000000 (Chrome)

Automatically reported Friday, May 27, 2016 at 2:40:39 PM

Provide additional details

Crash ID bbe2cb9c00000000 (Chrome)

Automatically reported Friday, May 27, 2016 at 2:40:36 PM

Provide additional details

Crash ID 730bcb9c00000000 (Chrome)

Automatically reported Friday, May 27, 2016 at 2:40:34 PM

Provide additional details

All the other crashes leads to 

0x00007f5c39ddcb92	(chrome -web_ui_controller.h:39 )	chromeos::OobeUI::OobeUI
0x00007f5c39cc7378	(chrome -bitset:1046 )	blink::CSSPropertyMetadata::isEnabledProperty
0x00007f5c39cc793e	(chrome -StringImpl.h:291 )	blink::AnimationEffectTimingProperties::AnimationEffectTimingProperties
0x00007f5c39cc7eb5	(chrome -FontFaceDescriptors.cpp:19 )	blink::FontFaceDescriptors::FontFaceDescriptors
0x00007f5c39cc4ab6	(chrome -HashTable.h:592 )	blink::StyleBuilderFunctions::applyInitialCSSPropertyGridTemplateRows
0x00007f5c39de8568	(chrome -signin_screen_handler.cc:821 )	chromeos::SigninScreenHandler::HideOfflineMessage
0x00007f5c3b6cd112	(chrome -cffl_iformfiller.cpp:751 )	CFFL_IFormFiller::OnClick
0x00007f5c3b6cd3ab	(chrome + 0x04e413ab )	
0x00007f5c3b6ca66c	(chrome -stl_deque.h:196 )	std::deque<PAGECHAR_INFO, std::allocator<PAGECHAR_INFO> >::_M_erase
0x00007f5c3a9bb125	(chrome -custom_button.cc:107 )	<name omitted>
0x00007f5c3a9bcaa1	(chrome -unique_ptr.h:76 )	views::ImageButton::~ImageButton
0x00007f5c3a9bcf7c	(chrome -image_button.cc:193 )	views::ImageButton::ComputeImagePaintPosition
0x00007f5c3a9b6dfc	(chrome -rect.h:41 )	views::BubbleFrameView::GetPreferredSize
0x00007f5c37a52b9e	(chrome -deflate.c:201 )	MOZ_Z_deflateSetDictionary

Yeah, every one of those stack traces looks like garbage. I'm not sure what there is to be done. Probably the only hope is to find someone who works on the crash reporting tool to double-check that the symbolization didn't go crazy.

Moving to CrashReporting for lack of a better component when "stack traces go bad". I don't know who owns that code who can look into it.

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot