search

zhpacer / google-breakpad

Automatically exported from code.google.com/p/google-breakpad
0 stars 0 forks source link

Arm stackwalk code doesn't take Link Register (LR) into account when outputing the top frame #638

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
I've recently been trying to figure out crbug.com/447208 and had an issue where 
the stacktrace didn't fully show the stacktrace.  The issue was that the code 
jumped to NULL.  Breakpad correctly reported the top stackframe as '0x0', but 
it then got all the other stackframes from the stack. Since the code jumped to 
NULL, the link register (LR) wasn't pushed onto the stack.  This means that the 
stacktrace didn't contain the actual stackframe which caused the "jump to 
NULL".  The issue is described in more detail on [1].

Can we use the LR in to figure out the top real frame in these situations?

[1] https://code.google.com/p/chromium/issues/detail?id=447208#c14

Original issue reported on code.google.com by rmcil...@chromium.org on 16 Feb 2015 at 7:34

GoogleCodeExporter commented 9 years ago 
It seems like this would be fairly straightforward:
https://code.google.com/p/google-breakpad/source/browse/trunk/src/processor/stac
kwalker_arm.cc#240

As long as you put it after the unwind-using-CFI rules it's unlikely to break 
things that would otherwise have produced a good stack. Maybe some heuristic 
there based on the previous frame's instruction pointer and lr would make it 
more solid?

Original comment by ted.mielczarek on 2 Apr 2015 at 12:31