Page MenuHomePhabricator

Fix TestMiniDump.py for Python 3
ClosedPublic

Authored by amccarth on Jan 8 2016, 3:41 PM.

Details

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.

Diff Detail

Repository
rL LLVM

Event Timeline

amccarth updated this revision to Diff 44385.Jan 8 2016, 3:41 PM
amccarth retitled this revision from to Fix TestMiniDump.py for Python 3.
amccarth updated this object.
amccarth added a reviewer: zturner.
amccarth added a subscriber: lldb-commits.
zturner edited edge metadata.Jan 8 2016, 6:36 PM
zturner added a subscriber: 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.

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 accepted this revision.Jan 11 2016, 8:10 AM
zturner edited edge metadata.

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.

This revision is now accepted and ready to land.Jan 11 2016, 8:10 AM
This revision was automatically updated to reflect the committed changes.