.raSearchStart in the cases where there are alignment operators in
the program string.
If alignment operators are found in the program string, the current
value of %ebp must be valid and it is the only reliable data point
that can be used for getting to the previous frame. Previously, the
.raSearchStart calculation was based on %esp and when %esp is aligned
in the current frame (which is a lossy operation) the resulting
.raSearchStart cannot was incorrect. There is code that is trying to
work around this problem (scanning of up to 3 words for a return
address) which is unreliable and it doesn't work in many cases (e.g.
when the alignment is on a 64-byte boundary).
This fix is already deployed in Google and it was measured to reduce
the number of wrong stack traces (for Windows crashes) by 45%. No
regressions have been found so far.
Here is an example of an issue that was fixed by this change (where
register %esp is aligned on the 64-byte boundary and the workarounds
that we already had didn't work):
https://code.google.com/p/chromium/issues/detail?id=311359
0:013> uf chrome_59630000!base::MessagePumpForIO::DoRunLoop
518 59685c39 55 push ebp
518 59685c3a 8bec mov ebp,esp
518 59685c3c 83e4c0 and esp,0FFFFFFC0h <== 64-byte boundary
518 59685c3f 83ec34 sub esp,34h
518 59685c42 53 push ebx
518 59685c43 56 push esi
Program string contains 64-byte alignment:
$T1 .raSearch = $T0 $T1 4 - 64 @ = $ebp $T1 4 - ^ = $eip $T1 ^ =
$esp $T1 4 + = $20 $T0 56 - ^ = $23 $T0 60 - ^ = $24 $T0 64 - ^ =
Review URL: https://breakpad.appspot.com/694002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1232 4c0a9323-5329-0410-9bdc-e9ce6186880e
fd9f3d8b17