From  wangxianzhu@:
Some stack frames look possible but some others look impossible, for example in https://uberchromegw.corp.google.com/i/chromium.perf/builders/Linux%20Perf%20%285%29/builds/14571/steps/rasterize_and_record_micro.top_25_smooth/logs/stdio:

	 0  chrome!blink::FramePainter::paintContents [FramePainter.cpp : 124 + 0x0]
          ^^ possible, but called from frame 7 instead of frame 1
	 1  chrome!blink::LayoutBlock::paint [LayoutBlock.cpp : 1253 + 0x5]
          ^^ not sure
	 2  chrome!blink::BlockPainter::paintChildren [BlockPainter.cpp : 99 + 0x12]
          ^^ not sure
	 3  chrome!blink::LayoutBlock::paintChildren [LayoutBlock.cpp : 1258 + 0x5]
          ^^ not sure
	 4  chrome!blink::BlockPainter::paintContents [BlockPainter.cpp : 253 + 0x14]
          ^^ not sure
	 5  chrome!blink::DragCaretController::caretLayoutObject [DragCaretController.cpp : 106 + 0x5]
          ^^ impossible
	 6  chrome!blink::ScrollableArea::excludeScrollbars [ScrollableArea.cpp : 607 + 0x9]
          ^^ impossible
	 7  chrome!blink::FramePainter::paint [FramePainter.cpp : 67 + 0xf]
          ^^ possible, but called from frame 10 instead of frame 8
	 8  chrome!blink::ReplacedPainter::shouldPaint [ReplacedPainter.cpp : 99 + 0x11]
          ^^ impossible
	 9  chrome!blink::BlockPainter::intersectsPaintRect [BlockPainter.cpp : 235 + 0x8]
          ^^ impossible
	10  chrome!blink::FrameView::paint [FrameView.cpp : 3790 + 0xa]
          ^^ correct
	11  chrome!blink::PartPainter::paintContents [PartPainter.cpp : 117 + 0x6]
          ^^ possible, but not called from frame 13 instead of frame 12
	12  chrome!blink::ReplacedPainter::shouldPaint [ReplacedPainter.cpp : 99 + 0x11]
          ^^ impossible. Ever called by PartPainter::paint, but should not in stack now
	13  chrome!blink::LayoutPart::paintContents [LayoutPart.cpp : 254 + 0x5]


Explanation from primiano@: 

"That stackwalk in #50 in unreliable, as it's based on stack scanning (you can see from the "Found by: stack scanning" messages on each frame)
Stack scanning is a last-resort unwinder in breakpad. Stack scanning will go nuts as soon as you have something that looks like a pointer to a .text section on the stack.
A good stackwalk should be based on CFI (Call Frame Info). 
It's weird that breakpad did not use CFI there. One reason that comes to my mind is that something is wrong in the symbol generation phase, and the exe file passed to generate_breakpad_symbols.py is lacking unwind tables. Maybe it's something that has to do with debug fission?
What is the exe file that is passed to generate_breakpad_symbols?"