Forced minidump creation by WriteMinidump() produces invalid call-stack on Windows

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Call WriteMinidump() somewhere in program
2. Use minidump_stackwalk to decode minidump. You'll see something like this:
Operating system: Windows NT
                  6.1.7601 Service Pack 1
CPU: x86
     GenuineIntel family 6 model 42 stepping 7
     4 CPUs

Crash reason:  EXCEPTION_NONCONTINUABLE_EXCEPTION
Crash address: 0x0

Thread 0 (crashed)
 0  0x2563940
    eip = 0x02563940   esp = 0x02568704   ebp = 0x0f66bdac   ebx = 0x66f4d6e0
    esi = 0x02555e30   edi = 0x0f3b591b   eax = 0x0045f72c   ecx = 0x0045f72c
    edx = 0x0045f6dc   efl = 0x00000212
    Found by: given as instruction pointer in context
...

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

As you can see, call-stack information about calling thread is missing, but 
other threads seem to be fine (see attached results from minudump_stackwalk). 
The same program will produce valid call-stack for crashed thread in case of 
real exception like access violation.

What version of the product are you using? On what operating system?

Windows 7 x32/x64, latest Google Breakpad from trunk.

Original issue reported on code.google.com by alexande...@gmail.com on 16 Dec 2013 at 11:21

Attachments:

• ae8d4429-21b4-4d2f-a35f-b41c5bace3eb.dmp.txt

[GoogleCodeExporter]

Console output from minidump_stackwalk, it's different from usual.

Original comment by alexande...@gmail.com on 16 Dec 2013 at 11:41

Attachments:

• out.txt

[GoogleCodeExporter]

What exact revision of Breakpad are you using? Can you try r1257 and see if it 
makes a difference?

Original comment by thestig@chromium.org on 17 Dec 2013 at 12:18

• Added labels: OpSys-Windows

[GoogleCodeExporter]

I'm using r1260.

Original comment by alexande...@gmail.com on 17 Dec 2013 at 12:24

[GoogleCodeExporter]

I suspect r1258 is bad. Thus I'm asking you to give r1257 a try.

Original comment by thestig@chromium.org on 17 Dec 2013 at 1:00

[GoogleCodeExporter]

r1257 gives me the same results. Are you able to reproduce this bug?

Original comment by alexande...@gmail.com on 17 Dec 2013 at 7:36

[GoogleCodeExporter]

No, I haven't tried. I just know r1258 is bad, so I was wondering if your 
problem was related. The EIP in your crash dump for the crashing thread seems 
wrong. There's nothing mapped at that memory address. I can try looking at this 
tomorrow.

Original comment by thestig@chromium.org on 17 Dec 2013 at 9:37

[GoogleCodeExporter]

I appreciate your help!
Let me know if I can help you in troubleshooting.

Original comment by alexande...@gmail.com on 17 Dec 2013 at 9:45

[GoogleCodeExporter]

Works ok here with the attached minimal test case:

Crash reason:  EXCEPTION_NONCONTINUABLE_EXCEPTION
Crash address: 0x0

Thread 0 (crashed)
 0  test.exe + 0x415c
    eip = 0x0110415c   esp = 0x0032fb90   ebp = 0x0032fbd0   ebx = 0x7efde000
    esi = 0x004f11f8   edi = 0x00000000   eax = 0x0032f884   ecx = 0x0032f884
    edx = 0x0032f834   efl = 0x00000206
    Found by: given as instruction pointer in context
 1  kernel32.dll + 0x1336a
    eip = 0x7656336a   esp = 0x0032fbd8   ebp = 0x0032fbdc
    Found by: previous frame's frame pointer
 2  ntdll.dll + 0x39f72
    eip = 0x77e69f72   esp = 0x0032fbe4   ebp = 0x0032fc1c
    Found by: previous frame's frame pointer
 3  ntdll.dll + 0x39f45
    eip = 0x77e69f45   esp = 0x0032fc24   ebp = 0x0032fc34
    Found by: previous frame's frame pointer

$ cl /I \path\to\breakpad\src test.cc
$ link test.obj exception_handler.lib crash_generation_client.lib common.lib
$ test.exe
start
filter
callback succeeded
WriteMinidump success
$

Original comment by thestig@chromium.org on 17 Dec 2013 at 10:26

Attachments:

• test.cc

[GoogleCodeExporter]

Finally find a cause of this "bug". Everything works fine if I use debug build 
with disabled optimization and inlining (/Od) but with /O2 (and maybe /Ob1) 
Breakpad SOMETIMES produces minidump like I've attached in my bugreport.
I use Breakpad in my project in this way - I created a wrapper for Breakpad and 
put it in a DLL which is compiled with /O2:

wrapper.cpp:
void generateDump()
{
    handler->WriteMinidump();
}

Then I call generateDump() from executable and give "invalid" minidump but if I 
compile wrapper.cpp with /Od (leaving the rest of DLL sources with /O2 
optimization) "correct" minidump will be generated!

I think that it would be nice to have list of possible issues and workarounds 
concerning compiler optimizations somewhere in wiki (maybe there is one 
already?).

Original comment by alexande...@gmail.com on 18 Dec 2013 at 6:08

[GoogleCodeExporter]

Can you try with the test.cc I attached and see if that has the same problem at 
/O2 ?

Original comment by thestig@chromium.org on 18 Dec 2013 at 6:47

[GoogleCodeExporter]

I've already tried - your example works fine with /O2.

Probably another test is required - create DLL with generateDump() as I 
described, compile it with /O2 and then call generateDump() from "outside".

Original comment by alexande...@gmail.com on 18 Dec 2013 at 6:58

[GoogleCodeExporter]

Since only you can reproduce it, please see if you can come up with a small 
test case to demonstrate this bug.

Original comment by thestig@chromium.org on 18 Dec 2013 at 7:36

[GoogleCodeExporter]

OK, will try.

Original comment by alexande...@gmail.com on 18 Dec 2013 at 7:47