Fix TestMiniDump.py for Python 3

[amccarth]

Summary

Under Python 3, lldb sees an extra frame on the stack, so I check that the stack has at least the number frames we expect.

Python 3 doesn't have dict.iteritems(). I used a wrapper function from six to keep this portable between the two versions.

[zturner]

What's the extra frame? Why does Python have an effect on the number of
frames seen by the minidump? Something seems wrong about that.

[amccarth]

In D16017#322830, @zturner wrote:

What's the extra frame? Why does Python have an effect on the number of
frames seen by the minidump? Something seems wrong about that.

Sorry, I misspoke. It has nothing to do with the version of Python. There's a new frame showing below main:

• thread #1: tid = 0x0454, 0x0004a00c a.out`int bar(x=3) + 12 at main.cpp:6, stop reason = breakpoint 1.1
  • frame #0: 0x0004a00c a.out`int bar(x=3) + 12 at main.cpp:6 frame #1: 0x0004a048 a.out`int foo(x=3) + 24 at main.cpp:13 frame #2: 0x0004a081 a.out`main + 33 at main.cpp:20 frame #3: 0x0004a49c a.out`$LN27 + 224

I suppose this might be from a change to the linker or the generation of debug info. Originally, the deepest frame that showed was main.

[zturner]

In D16017#323550, @amccarth wrote:

In D16017#322830, @zturner wrote:

What's the extra frame? Why does Python have an effect on the number of
frames seen by the minidump? Something seems wrong about that.

Sorry, I misspoke. It has nothing to do with the version of Python. There's a new frame showing below main:

• thread #1: tid = 0x0454, 0x0004a00c a.out`int bar(x=3) + 12 at main.cpp:6, stop reason = breakpoint 1.1
  • frame #0: 0x0004a00c a.out`int bar(x=3) + 12 at main.cpp:6 frame #1: 0x0004a048 a.out`int foo(x=3) + 24 at main.cpp:13 frame #2: 0x0004a081 a.out`main + 33 at main.cpp:20 frame #3: 0x0004a49c a.out`$LN27 + 224

I suppose this might be from a change to the linker or the generation of debug info. Originally, the deepest frame that showed was main.

Meh. This reminds me of why I wanted to check in the dump file. We're seeing different call stacks with different compilers. But I guess this is fine.

lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py

 """
 Test basics of mini dump debugging.
 """
 
 from __future__ import print_function
-
+from six import iteritems
 
 
 import lldb
 from lldbsuite.test.lldbtest import *
 import lldbsuite.test.lldbutil as lldbutil
 
 class MiniDumpTestCase(TestBase):
 
def test_deeper_stack_in_mini_dump(self):
             self.assertTrue(process.Kill().Success())
 
             # Launch with the mini dump, and inspect the stack.
             target = self.dbg.CreateTarget(None)
             process = target.LoadCore(core)
             thread = process.GetThreadAtIndex(0)
 
             expected_stack = { 0: 'bar', 1: 'foo', 2: 'main' }
-            self.assertEqual(thread.GetNumFrames(), len(expected_stack))
-            for index, name in expected_stack.iteritems():
+            self.assertGreaterEqual(thread.GetNumFrames(), len(expected_stack))
+            for index, name in iteritems(expected_stack):
                 frame = thread.GetFrameAtIndex(index)
                 self.assertTrue(frame.IsValid())
                 function_name = frame.GetFunctionName()
                 self.assertTrue(name in function_name)
 
         finally:
             # Clean up the mini dump file.
             self.assertTrue(self.dbg.DeleteTarget(target))