[lldb-dev] [Bug 35193] New: MiniDumpTestCase.test_stack_info_in_minidump failing

[via lldb-dev]

https://bugs.llvm.org/show_bug.cgi?id=35193

            Bug ID: 35193
           Summary: MiniDumpTestCase.test_stack_info_in_minidump failing
           Product: lldb
           Version: unspecified
          Hardware: PC
                OS: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: lldb-dev at lists.llvm.org
          Reporter: labath at google.com
                CC: amccarth at google.com, llvm-bugs at lists.llvm.org

In r316673 we enabled the SysV-i386 ABI plugin for windows targets (among
others).
This caused MiniDumpTestCase.test_stack_info_in_minidump to start failing
because it was asserting that we only see one frame in the minidump. This was
no longer true, because the ABI plugin provided lldb with a "architecture
default unwind plan", which tells it to follow the %ebp chain. Using this
method lldb was able to find 5 more frames in the minidump.

I inspected the minidump manually and confirmed that lldb followed the ebp
chain correctly, so I updated the test expectation to the new backtrace
(r316688).

However, this test still continues to fail on windows because there lldb finds
kernel32.dll somewhere on the system and loads it, which changes the unwind
strategy and the computed backtrace. Furthermore, the computed backtrace is
almost always wrong because the loaded kernel32.dll is most likely different
from the dll that was present in the original process.

I think there are at least two bugs here:
1. lldb loads kernel32.dll even though it does not match. The minidump seems to
contain some sort of a checksum next to each module, so this can probably be
fixed by verifying those checksums before loading.

2. (this is probably more like a feature request) For the sake of test
reproducibility, we should have a way to prevent lldb from loading libraries
from the host system (perhaps by having a --sysroot argument that tells it
where to search for files, and then just pointing that to an empty folder).

I am going to xfail the test until this can be somehow fixed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20171103/95a1c04b/attachment.html>