summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/minidump
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix "default argument for lambda parameter" (-Wpedantic) warningPavel Labath2018-12-271-2/+2
| | | | llvm-svn: 350089
* Overload GetMemoryRegions for the ProcessMinidumpTatyana Krasnukha2018-12-205-3/+22
| | | | | | Differential Revision: https://reviews.llvm.org/D55841 llvm-svn: 349767
* Add "dump" command as a custom "process plugin" subcommand when ↵Greg Clayton2018-12-185-1/+300
| | | | | | | | | | | | | | | | | ProcessMinidump is used. Each process plug-in can create its own custom commands. I figured it would be nice to be able to dump things from the minidump file from the lldb command line, so I added the start of the some custom commands. Currently you can dump: minidump stream directory all linux specifc streams, most of which are strings each linux stream individually if desired, or all with --linux The idea is we can expand the command set to dump more things, search for data in the core file, and much more. This patch gets us started. Differential Revision: https://reviews.llvm.org/D55727 llvm-svn: 349429
* Cache memory regions in ProcessMinidump and use the linux maps as the source ↵Greg Clayton2018-12-144-89/+183
| | | | | | | | | | | | | | | | | | | | | | | of the information if available Breakpad creates minidump files that sometimes have: - linux maps textual content - no MemoryInfoList Right now unless the file has a MemoryInfoList we get no region information. This patch: - reads and caches the memory region info one time and sorts it for easy subsequent access - get the region info from the best source in this order: - linux maps info (if available) - MemoryInfoList (if available) - MemoryList or Memory64List - returns memory region info for the gaps between regions (before the first and after the last) Differential Revision: https://reviews.llvm.org/D55522 llvm-svn: 349182
* Fix MinidumpParser::GetFilteredModuleList() and test itGreg Clayton2018-12-131-19/+28
| | | | | | | | | | The MinidumpParser::GetFilteredModuleList() code was attempting to iterate through the entire module list and if it found more than one entry for a given module name, it wanted to pick the MinidumpModule with the lowest address. A bug existed where it wasn't doing that due to "exists" variable being inverted. "exists" was set to true if it was inserted, not if it existed. Furthermore, the order of the modules would be modified by sorting all modules from low address to high address (using MinidumpModule::base_of_image). This fix also maintains the original order which means your executable is at index 0 as intended instead of some random shared library. Tests were added to ensure this functionality doesn't regress. Differential Revision: https://reviews.llvm.org/D55614 llvm-svn: 349062
* Re-land "Extract construction of DataBufferLLVM into FileSystem"Jonas Devlieghere2018-11-121-4/+4
| | | | | | This fixes some UB in isLocal detected by the sanitized bot. llvm-svn: 346707
* Revert "Extract construction of DataBufferLLVM into FileSystem"Davide Italiano2018-11-121-4/+4
| | | | | | It broke the lldb sanitizer bots. llvm-svn: 346694
* Remove header grouping comments.Jonas Devlieghere2018-11-1116-37/+0
| | | | | | | | This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. llvm-svn: 346626
* Extract construction of DataBufferLLVM into FileSystemJonas Devlieghere2018-11-101-4/+4
| | | | | | | | | | This moves construction of data buffers into the FileSystem class. Like some of the previous refactorings we don't translate the path yet because the functionality hasn't been landed in LLVM yet. Differential revision: https://reviews.llvm.org/D54272 llvm-svn: 346598
* [FileSystem] Move path resolution logic out of FileSpecJonas Devlieghere2018-11-011-2/+2
| | | | | | | | | This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
* Don't include the Age in the UUID for CvRecordPdb70 UUID records in minidump ↵Greg Clayton2018-08-291-2/+12
| | | | | | | | | | | | | | | | | files for Apple vendors. The CvRecordPdb70 structure looks like: struct CvRecordPdb70 { uint8_t Uuid[16]; llvm::support::ulittle32_t Age; // char PDBFileName[]; }; We were including the "Age" in the UUID for Apple vedors which caused us to not be able to match the UUID to built binaries. The "Age" field is set to zero in breakpad minidump files for Apple targets. Differential Revision: https://reviews.llvm.org/D51442 llvm-svn: 340966
* Restrict the set of plugins used for ProcessMinidumpLeonard Mosescu2018-08-232-8/+15
| | | | | | | | | | | | | | 1. The dynamic loaders should not be needed for loading minidumps and they may create problems (ex. the macOS loader resets the list of loaded sections, which for minidumps are already set up during minidump loading) 2. In general, the extra plugins can do extraneous work which hurts performance (ex. trying to set up implicit symbolic breakpoints, which in turn will trigger extra debug information loading) Differential Revision: https://reviews.llvm.org/D51176 llvm-svn: 340578
* Misc module/dwarf logging improvementsLeonard Mosescu2018-08-071-0/+6
| | | | | | | | | | | | | | This change improves the logging for the lldb.module category to note a few interesting cases: 1. Local object file found, but specs not matching 2. Local object file not found, using a placeholder module The handling and logging for the cases wehre we fail to load compressed dwarf symbols is also improved. Differential Revision: https://reviews.llvm.org/D50274 llvm-svn: 339161
* Fix a couple of extended-offsetof warnings that had slipped throughPavel Labath2018-08-071-3/+3
| | | | llvm-svn: 339130
* Move RegisterValue,Scalar,State from Core to UtilityPavel Labath2018-08-073-3/+3
| | | | | | | | | | | | | These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely). The XCode project will need to be updated after this change. Differential Revision: https://reviews.llvm.org/D49740 llvm-svn: 339127
* Fix more offsetof issues.Greg Clayton2018-08-061-5/+5
| | | | llvm-svn: 339034
* Fix offsetof usage that got lost when passing patches between linux and mac.Greg Clayton2018-08-062-14/+16
| | | | llvm-svn: 339033
* Add support for ARM and ARM64 breakpad generated minidump files (version 2).Greg Clayton2018-08-069-18/+1597
| | | | | | | | | | | | | | | | In this patch I add support for ARM and ARM64 break pad files. There are two flavors of ARM: Apple where FP is R7, and non Apple where FP is R11. Added minimal tests that load up ARM64 and the two flavors or ARM core files with a single thread and known register values in each register. Each register is checked for the exact value. This is a fixed version of: https://reviews.llvm.org/D49750 The changes from D49750 are: Don't init the m_arch in the Initialize call as a system info isn't required. This keeps the thread list, module list and other tests from failing Added -Wextended-offsetof to Xcode project so we catch use extended usages of offsetof before submission Fixed any extended offset of warnings Differential Revision: https://reviews.llvm.org/D50336 llvm-svn: 339032
* Revert "Add support for ARM and ARM64 breakpad generated minidump files"Pavel Labath2018-08-039-1653/+76
| | | | | | | | This reverts commit r338734 (and subsequent fixups in r338772 and r338746), because it breaks some minidump unit tests and introduces a lot of compiler warnings. llvm-svn: 338828
* [lldb] Remove unused variable.David L. Jones2018-08-021-1/+0
| | | | | | The use of this variable was removed in r338734. It now causes unused variable warnings. llvm-svn: 338772
* Fix CMake build.Zachary Turner2018-08-021-0/+2
| | | | | | | Some new files were committed to the repository but not added to the CMakeLists.txt, so this patch fixes the build. llvm-svn: 338746
* Add support for ARM and ARM64 breakpad generated minidump filesGreg Clayton2018-08-028-75/+1651
| | | | | | | | In this patch I add support for ARM and ARM64 break pad files. There are two flavors of ARM: Apple where FP is R7, and non Apple where FP is R11. Added minimal tests that load up ARM64 and the two flavors or ARM core files with a single thread and known register values in each register. Each register is checked for the exact value. Differential Revision: https://reviews.llvm.org/D49750 llvm-svn: 338734
* Add support for parsing Breakpad minidump files that can have extra padding ↵Greg Clayton2018-07-231-2/+19
| | | | | | | | in the module, thread and memory lists. Differential Revision: https://reviews.llvm.org/D49579 llvm-svn: 337694
* Restructure the minidump loading path and add early & explicit consistency ↵Leonard Mosescu2018-07-124-47/+139
| | | | | | | | | | | | | | | | | | | | | checks Corrupted minidumps was leading to unpredictable behavior. This change adds explicit consistency checks for the minidump early on. The checks are not comprehensive but they should catch obvious structural violations: streams with type == 0 duplicate streams (same type) overlapping streams truncated minidumps Another early check is to make sure we actually support the minidump architecture instead of crashing at a random place deep inside LLDB. Differential Revision: https://reviews.llvm.org/D49202 llvm-svn: 336918
* Remove unused variable m_header as it hasn't been used since it wasEric Christopher2018-07-122-6/+4
| | | | | | added in 2016. llvm-svn: 336884
* Represent invalid UUIDs as UUIDs with length zeroPavel Labath2018-06-261-12/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: During the previous attempt to generalize the UUID class, it was suggested that we represent invalid UUIDs as length zero (previously, we used an all-zero UUID for that). This meant that some valid build-ids could not be represented (it's possible however unlikely that a checksum of some file would be zero) and complicated adding support for variable length build-ids (should a 16-byte empty UUID compare equal to a 20-byte empty UUID?). This patch resolves these issues by introducing a canonical representation for an invalid UUID. The slight complication here is that some clients (MachO) actually use the all-zero notation to mean "no UUID has been set". To keep this use case working (while making it very explicit about which construction semantices are wanted), replaced the UUID constructors and the SetBytes functions with named factory methods. - "fromData" creates a UUID from the given data, and it treats all bytes equally. - "fromOptionalData" first checks the data contents - if all bytes are zero, it treats this as an invalid/empty UUID. Reviewers: clayborg, sas, lemo, davide, espindola Subscribers: emaste, lldb-commits, arichardson Differential Revision: https://reviews.llvm.org/D48479 llvm-svn: 335612
* Normalize some lldb #include statements.James Y Knight2018-05-221-2/+0
| | | | | | | | | | | Most non-local includes of header files living under lldb/sources/ were specified with the full path starting after sources/. However, in a few instances, other sub-directories were added to include paths, or Normalize those few instances to follow the style used by the rest of the codebase, to make it easier to understand. llvm-svn: 333035
* Use the UUID from the minidump's CodeView Record for placeholder modulesLeonard Mosescu2018-05-024-4/+60
| | | | | | | | | | | | | | | This change adds support for two types of Minidump CodeView records: PDB70 (reference: https://crashpad.chromium.org/doxygen/structcrashpad_1_1CodeViewRecordPDB70.html) This is by far the most common record type. ELF BuildID (found in Breakpad/Crashpad generated minidumps) This would set a proper UUID for placeholder modules, in turn enabling an accurate match with local module images. Differential Revision: https://reviews.llvm.org/D46292 llvm-svn: 331394
* Reflow paragraphs in comments.Adrian Prantl2018-04-303-30/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
* Attempt to fix TestMiniDump on windowsPavel Labath2018-04-191-1/+2
| | | | | | | | | | | | | | | | | | | | | | | It was failing because the modules names were coming out as C:\Windows\System32/MSVCP120D.dll (last separator is a forward slash) on windows. There are two issues at play here: - the first problem is that the paths in minidump were being parsed as a host path. This meant that on posix systems the whole path was interpreted as a file name. - on windows the path was split into a directory-filename pair correctly, but then when it was reconsituted, the last separator ended up being a forward slash because SBFileSpec.fullpath was joining them with '/' unconditionally. I fix the first issue by parsing the minidump paths according to the path syntax of the host which produced the dump, which should make the test behavior on posix&windows identical. The last path will still be a forward slash because of the second issue. We should probably fix the "fullpath" property to do something smarter in the future. llvm-svn: 330314
* Improve LLDB's handling of non-local minidumpsLeonard Mosescu2018-04-182-1/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally, LLDB is creating a high-fidelity representation of a live process, including a list of modules and sections, with the associated memory address ranges. In order to build the module and section map LLDB tries to locate the local module image (object file) and will parse it. This does not work for postmortem debugging scenarios where the crash dump (minidump in this case) was captured on a different machine. Fortunately the minidump format encodes enough information about each module's memory range to allow us to create placeholder modules. This enables most LLDB functionality involving address-to-module translations. Also, we may want to completly disable the search for matching local object files if we load minidumps unless we can prove that the local image matches the one from the crash origin. (not part of this change, see: llvm.org/pr35193) Example: Identify the module from a stack frame PC: Before: thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14 frame #0: 0x00164d14 frame #1: 0x00167c79 frame #2: 0x00167e6d frame #3: 0x7510336a frame #4: 0x77759882 frame #5: 0x77759855 After: thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14 frame #0: 0x00164d14 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe frame #1: 0x00167c79 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe frame #2: 0x00167e6d C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe frame #3: 0x7510336a C:\Windows\SysWOW64\kernel32.dll frame #4: 0x77759882 C:\Windows\SysWOW64\ntdll.dll frame #5: 0x77759855 C:\Windows\SysWOW64\ntdll.dll Example: target modules list Before: error: the target has no associated executable images After: [ 0] C:\Windows\System32\MSVCP120D.dll [ 1] C:\Windows\SysWOW64\kernel32.dll [ 2] C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe [ 3] C:\Windows\System32\MSVCR120D.dll [ 4] C:\Windows\SysWOW64\KERNELBASE.dll [ 5] C:\Windows\SysWOW64\ntdll.dll NOTE: the minidump format also includes the debug info GUID, so we can fill-in the module UUID from it, but this part was excluded from this change to keep the changes simple (the LLDB UUID is hardcoded to be either 16 or 20 bytes, while the CodeView GUIDs are normally 24 bytes) Differential Revision: https://reviews.llvm.org/D45700 llvm-svn: 330302
* Prevent unaligned memory read in parseMinidumpStringRaphael Isemann2018-01-231-5/+10
| | | | | | | | | | | | | | | | | | | Summary: It's possible to hit an unaligned memory read when reading `source_length` as the `data` array is only aligned with 2 bytes (it's actually a UTF16 array). This patch memcpy's `source_length` into a local variable to prevent this: ``` MinidumpTypes.cpp:49:23: runtime error: load of misaligned address 0x7f0f4792692a for type 'const uint32_t' (aka 'const unsigned int'), which requires 4 byte alignment ``` Reviewers: dvlahovski, zturner, davide Reviewed By: davide Subscribers: davide, lldb-commits Differential Revision: https://reviews.llvm.org/D42348 llvm-svn: 323181
* elf-core: Convert remaining register context to use register set mapsPavel Labath2017-11-281-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In https://reviews.llvm.org/D39681, we started using a map instead passing a long list of register sets to the ppc64le register context. However, existing register contexts were still using the old method. This converts the remaining register contexts to use this approach. While doing that, I've had to modify the approach a bit: - the general purpose register set is still kept as a separate field, because this one is always present, and it's parsing is somewhat different than that of other register sets. - since the same register sets have different IDs on different operating systems, but we use the same register context class to represent different register sets, I've needed to add a layer of indirection to translate os-specific constants (e.g. NETBSD::NT_AMD64_FPREGS) into more generic terms (e.g. floating point register set). While slightly more complicated, this setup allows for better separation of concerns. The parsing code in ProcessElfCore can focus on parsing OS-specific core file notes, and can completely ignore architecture-specific register sets (by just storing any unrecognised notes in a map). These notes will then be passed on to the architecture-specific register context, which can just deal with architecture specifics, because the OS-specific note types are hidden in a register set description map. This way, adding an register set, which is already supported on other OSes, to a new OS, should in most cases be as simple as adding a new entry into the register set description map. Differential Revision: https://reviews.llvm.org/D40133 llvm-svn: 319162
* Move ArchSpec to the Utility modulePavel Labath2017-11-131-2/+1
| | | | | | | | | | | | | The rationale here is that ArchSpec is used throughout the codebase, including in places which should not depend on the rest of the code in the Core module. This commit touches many files, but most of it is just renaming of #include lines. In a couple of cases, I removed the #include ArchSpec line altogether, as the file was not using it. In one or two places, this necessitated adding other #includes like lldb-private-defines.h. llvm-svn: 318048
* Re-land r313210 - Fix for bug 34532 - A few rough corners related to ↵Adrian McCarthy2017-09-191-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | post-mortem debugging (core/minidump) The main change is to avoid setting the process state as running when debugging core/minidumps (details in the bug). Also included a few small, related fixes around how the errors propagate in this case. Fixed the FreeBSD/Windows break: the intention was to keep Process::WillResume() and Process::DoResume() "in-sync", but this had the unfortunate consequence of breaking Process sub-classes which don't override WillResume(). The safer approach is to keep Process::WillResume() untouched and only override it in the minidump and core implementations. patch by lemo Bug: https://bugs.llvm.org/show_bug.cgi?id=34532 Differential Revision: https://reviews.llvm.org/D37651 llvm-svn: 313655
* Fix for bug 34510 - Minidump target does not resolve new symbols correctlyAdrian McCarthy2017-09-072-4/+0
| | | | | | | | | | | | | | | | Even though the content of the minidump does not change in a debugging session, frames can't be indiscriminately be cached since modules and symbols can be explicitly added after the minidump is loaded. The fix is simple, just let the base Thread::ClearStackFrames() do its job. submitted by amccarth on behalf of lemo Bug: https://bugs.llvm.org/show_bug.cgi?id=34510 Differential Revision: https://reviews.llvm.org/D37527 llvm-svn: 312735
* Rename Error -> Status.Zachary Turner2017-05-126-34/+34
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* Remove FileSpec::ReadFileContents.Zachary Turner2017-03-061-2/+2
| | | | | | | | | | | | | | | | This functionality is subsumed by DataBufferLLVM, which is also more efficient since it will try to mmap. However, we don't yet support mmaping writable private sections, and in some cases we were using ReadFileContents and then modifying the buffer. To address that I've added a flag to the DataBufferLLVM methods that allow you to map privately, which disables the mmaping path entirely. Eventually we should teach DataBufferLLVM to use mmap with writable private, but that is orthogonal to this effort. Differential Revision: https://reviews.llvm.org/D30622 llvm-svn: 297095
* Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner2017-03-045-7/+7
| | | | llvm-svn: 296943
* Move Log from Core -> Utility.Zachary Turner2017-03-032-2/+2
| | | | | | | | | All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
* Delete DataBufferMemoryMap.Zachary Turner2017-02-241-9/+15
| | | | | | | | | | | | | | | After a series of patches on the LLVM side to get the mmaping code up to compatibility with LLDB's needs, it is now ready to go, which means LLDB's custom mmapping code is redundant. So this patch deletes it all and uses LLVM's code instead. In the future, we could take this one step further and delete even the lldb DataBuffer base class and rely entirely on LLVM's facilities, but this is a job for another day. Differential Revision: https://reviews.llvm.org/D30054 llvm-svn: 296159
* Switch std::call_once to llvm::call_onceKamil Rytarowski2017-02-061-2/+4
| | | | | | | | | | | | | | | | | | | | | Summary: The std::call_once implementation in libstdc++ has problems on few systems: NetBSD, OpenBSD and Linux PPC. LLVM ships with a homegrown implementation llvm::call_once to help on these platforms. This change is required in the NetBSD LLDB port. std::call_once with libstdc++ results with crashing the debugger. Sponsored by <The NetBSD Foundation> Reviewers: labath, joerg, emaste, mehdi_amini, clayborg Reviewed By: labath, clayborg Subscribers: #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D29288 llvm-svn: 294202
* Move classes from Core -> Utility.Zachary Turner2017-02-023-4/+4
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* [CMake] [3/4] Update a batch of pluginsChris Bieneman2017-01-311-1/+10
| | | | | | This is extending the updates from r293696 to more LLDB plugins. llvm-svn: 293700
* Prevent at compile time converting from Error::success() to Expected<T>Mehdi Amini2016-11-111-1/+1
| | | | | | | | This would trigger an assertion at runtime otherwise. Differential Revision: https://reviews.llvm.org/D26482 llvm-svn: 286562
* Make the Error class constructor protectedMehdi Amini2016-11-111-1/+1
| | | | | | | | | This is forcing to use Error::success(), which is in a wide majority of cases a lot more readable. Differential Revision: https://reviews.llvm.org/D26481 llvm-svn: 286561
* Disable windows-only minidump pluginPavel Labath2016-11-091-5/+1
| | | | | | | | | | | | | | | | | Summary: This commit disables the windows-only minidump plugin and enables the new cross-platform plugin for windows minidump files. Test decorators are adjusted to reflect that: windows minidump tests can now run on all platforms. The exception is the tests that create minidump files, as that functionality is not available yet. I've checked that this works on windows and linux. Reviewers: amccarth, zturner Subscribers: dvlahovski, lldb-commits Differential Revision: https://reviews.llvm.org/D26393 llvm-svn: 286352
* Fix some warnings compiling with clang-cl on Windows.Zachary Turner2016-11-021-1/+1
| | | | llvm-svn: 285834
* Fix printf errors in ProcessMinidumpPavel Labath2016-11-021-6/+6
| | | | llvm-svn: 285798
* Minidump plugin: Fix flaky testDimitar Vlahovski2016-11-012-9/+22
| | | | | | | | | | | | | | | | | | | Summary: One of the tests was flaky, because similarly to https://reviews.llvm.org/D18697 (rL265391) - if there is a process running which is with the same PID as in the core file, the minidump core file debugging will fail, because we get some information from the running process. The fix is routing the ProcessInfo requests through the Process class and overriding it in ProcessMinidump to return correct data. Reviewers: labath Subscribers: lldb-commits, beanz Differential Revision: https://reviews.llvm.org/D26193 llvm-svn: 285698
OpenPOWER on IntegriCloud