Add first tests for mini-dump debugging.

[amccarth]

Summary

This includes a dump file captured using Visual Studio, of the enclosed sample program, which was also build with Visual Studio.

The tests just verify that LLDB can access some very basic information from the mini-dump.

[zturner]

Instead of test/functionalities/minidump, I would probably call this test/functionalities/core-file/windows.

I'm using core-file instead of minidump because it's the most generic term that will make sense on all platforms, and other platforms will essentially want to add tests for this. And I'm making a windows subdirectory because we're going to have enough of these eventually that we'll want to separate them.

test/functionalities/minidump/TestMiniDump.py

14

I think you can actually put this at the class level, then you don't need it on individual tests.

29

Do we not have a way to get the exception code?

39–41

This can go away

[amccarth]

Instead of test/functionalities/minidump, I would probably call this test/functionalities/core-file/windows.

Hmm...

There is talk of (eventually) debugging minidumps on other platforms. Also some crash capture tools can make minidumps, even on Mac and Linux hosts. I could imagine you might also want to be able to debug a core file from a non-Windows host on a Windows host. So core-file/windows could end up being confusing/misleading in the long run.

How about

test/functionalities/crash_files/core-files

and

test/functionalities/crash_files/mini-dumps

?

test/functionalities/minidump/TestMiniDump.py

29

Unfortunately, no.

It looks like you can, because the API has methods for getting extra values associated with the stop reason (SBThread::GetStopReasonDataCount and SBThread::GetStopReasonDataAtIndex), but no data about exceptions is not plumbed through--the process plugins just generate a string description and attach it to the stop reason. I spent quite a bit of time discovering this.

I would like to make the process plugins provide the information in a way that makes it available through those APIs as a separate patch.

[zturner]

In D12888#247195, @amccarth wrote:

Instead of test/functionalities/minidump, I would probably call this test/functionalities/core-file/windows.

Hmm...

There is talk of (eventually) debugging minidumps on other platforms. Also some crash capture tools can make minidumps, even on Mac and Linux hosts. I could imagine you might also want to be able to debug a core file from a non-Windows host on a Windows host. So core-file/windows could end up being confusing/misleading in the long run.

How about

test/functionalities/crash_files/core-files

and

test/functionalities/crash_files/mini-dumps

?

Are the "mini dumps" you're referring to that can be created on a Mac or Linux host the same file format? I think we need some way to capture the distinction between the two file formats. All of the different formats have one thing in common though. They support *postmortem* debugging. So maybe it could be:

test/functionalities/postmortem/elf

test/functionalities/postmortem/windows

I don't think having it be called "windows" precludes being able to use the functionality on non-windows hosts (provided we ever write a library that can process them on non-Windows), I just can't think of a better way to describe the format itself.

[amccarth]

In D12888#247212, @zturner wrote:

In D12888#247195, @amccarth wrote:

Instead of test/functionalities/minidump, I would probably call this test/functionalities/core-file/windows.

Hmm...

There is talk of (eventually) debugging minidumps on other platforms. Also some crash capture tools can make minidumps, even on Mac and Linux hosts. I could imagine you might also want to be able to debug a core file from a non-Windows host on a Windows host. So core-file/windows could end up being confusing/misleading in the long run.

How about

test/functionalities/crash_files/core-files

and

test/functionalities/crash_files/mini-dumps

?

Are the "mini dumps" you're referring to that can be created on a Mac or Linux host the same file format? I think we need some way to capture the distinction between the two file formats. All of the different formats have one thing in common though. They support *postmortem* debugging. So maybe it could be:

test/functionalities/postmortem/elf

test/functionalities/postmortem/windows

I don't think having it be called "windows" precludes being able to use the functionality on non-windows hosts (provided we ever write a library that can process them on non-Windows), I just can't think of a better way to describe the format itself.

Note that Breakpad uses the Windows minidump format for all platforms: https://code.google.com/p/google-breakpad/wiki/GettingStartedWithBreakpad#The_minidump_file_format

So it makes sense to distinguish based on crash file type rather than platform. Thus, per offline discussion, we'll go with:

test/functionalities/postmortem/minidump

In the future, we can add tests for core files in:

test/functionalities/postmortem/core

[amccarth]

Addressed earlier comments and moved to functionalities\postmortem\minidump

[zturner]

looks fine.

test/functionalities/minidump/TestMiniDump.py

+"""
+Test basics of mini dump debugging.
+"""
+
+import unittest2
+import lldb
+from lldbtest import *
+import lldbutil
+
+class MiniDumpTestCase(TestBase):
+
+    mydir = TestBase.compute_mydir(__file__)
+
+    @skipUnlessWindows  # for now mini-dump debugging is limited to Windows hosts
+    def test_process_info_in_mini_dump(self):
+        """Test that lldb can read the process information from the minidump."""
+        self.assertTrue(self.process, PROCESS_IS_VALID)
+        self.assertEqual(self.process.GetNumThreads(), 1)
+        # TODO(amccarth):  Check the process ID.
+
+    @skipUnlessWindows  # for now mini-dump debugging is limited to Windows hosts
+    def test_thread_info_in_mini_dump(self):
+        """Test that lldb can read the thread information from the minidump."""
+        # This process crashed due to an access violation (0xc0000005) in its one and only thread.
+        self.assertEqual(self.process.GetNumThreads(), 1)
+        thread = self.process.GetThreadAtIndex(0)
+        self.assertEqual(thread.GetStopReason(), lldb.eStopReasonException)
+        stop_description = thread.GetStopDescription(256);
+        self.assertTrue("0xc0000005" in stop_description);
+
+    def setUp(self):
+        # Call super's setUp().
+        TestBase.setUp(self)
+        # target create -c fizzbuzz_no_heap.dmp
+        self.dbg.CreateTarget("")
+        self.target = self.dbg.GetSelectedTarget()
+        self.process = self.target.LoadCore("fizzbuzz_no_heap.dmp")
+
+    def tearDown(self):
+        # Call super's tearDown().
+        TestBase.tearDown(self)
+
+if __name__ == '__main__':
+    import atexit
+    lldb.SBDebugger.Initialize()
+    atexit.register(lambda: lldb.SBDebugger.Terminate())
+    unittest2.main()

test/functionalities/minidump/fizzbuzz.cpp

+// A sample program for getting minidumps on Windows.
+
+#include <iostream>
+
+bool
+fizz(int x)
+{
+    return x % 3 == 0;
+}
+
+bool
+buzz(int x)
+{
+    return x % 5 == 0;
+}
+
+int
+main()
+{
+    int *buggy = 0;
+
+    for (int i = 1; i <= 100; ++i)
+    {
+        if (fizz(i)) std::cout << "fizz";
+        if (buzz(i)) std::cout << "buzz";
+        if (!fizz(i) && !buzz(i)) std::cout << i;
+        std::cout << '\n';
+    }
+
+    return *buggy;
+}

test/lldbtest.py

     """Decorate the item to skip tests that should be skipped on Windows."""
     return skipIfHostPlatform(["windows"])(func)
 
+def skipUnlessWindows(func):
+    """Decorate the item to skip tests that should be skipped on any non-Windows platform."""
+    return skipUnlessPlatform(["windows"])(func)
+
 def skipUnlessDarwin(func):
     """Decorate the item to skip tests that should be skipped on any non Darwin platform."""
     return skipUnlessPlatform(getDarwinOSTriples())(func)