Breakpad stackwalker fails on certain x86 CPU models for the Win32 platform

[GoogleCodeExporter]

What steps will reproduce the problem?

In order to reproduce the issue, let breakpad process a Windows x86 minidump 
produced on one of the following CPU families:
   - GenuineIntel family 6 model 26
     First gen Core i-series.
   - GenuineIntel family 6 model 30
     First gen Core i-series.
   - GenuineIntel family 6 model 37
     First gen Core i-series.
   - GenuineIntel family 6 model 42
     Sandy Bridge / second gen Core i-series.
   - GenuineIntel family 6 model 58
     Ivy Bridge / third gen Core i-series.

What is the expected output? What do you see instead?

I'm expecting to see the following:

0:000> kL
ChildEBP RetAddr  
002ff290 75fa0a91 ntdll!NtWaitForSingleObject+0x15
002ff2fc 75741194 KERNELBASE!WaitForSingleObjectEx+0x98
002ff314 75741148 kernel32!WaitForSingleObjectExImplementation+0x75
002ff328 6491ece0 kernel32!WaitForSingleObject+0x12
002ff33c 64a2d039 chrome_647f0000!base::WaitableEvent::TimedWait+0x2d
[..snip..]

Instead, I'm getting this:

Thread 0

0x771ef8c1   [ntdll.dll]     + 0x0001f8c1]  ZwWaitForSingleObject
0x771ef8c0   [ntdll.dll]     + 0x0001f8c0]  ZwWaitForSingleObject
0x64a07ff0   [chrome.dll]    - 
transport_security_persister.cc:105]    TransportSecurityPersister::SerializeData(s
td::basic_string<char,std::char_traits<char>,std::allocator<char> > *)
0x75741193   [kernel32.dll]  + 0x00011193]  WaitForSingleObjectExImplementation
0x75741147   [kernel32.dll]  + 0x00011147]  WaitForSingleObject
0x6491ecdf   [chrome.dll]    - 
waitable_event_win.cc:63]   base::WaitableEvent::TimedWait(base::TimeDelta const 
&)
[..snip..]

It appears that this is a very common pattern which can be recognized as 
follows:
    - The top two frames look like a recursive call done by a system function (very weird indeed)
    - The real return address from the system function (second frame) is missing
    - The third frame is very often random crap (execution residue from the stack)
    - In most cases, the call stack below the fourth frame looks good.
In some cases, we can’t recover and the stack is truncated

Original issue reported on code.google.com by iva...@google.com on 7 Jun 2012 at 12:05

[GoogleCodeExporter]

Original comment by iva...@google.com on 12 Dec 2012 at 11:47

[GoogleCodeExporter]

Fixed by http://code.google.com/p/google-breakpad/source/detail?r=971

Original comment by ivan.penkov on 12 Dec 2012 at 11:51

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by ivan.penkov on 12 Dec 2012 at 11:53

• Changed state: Verified