crashpad/snapshot/win/process_reader_win_test.cc

208 lines
6.1 KiB
C++
Raw Normal View History

// Copyright 2015 The Crashpad Authors. All rights reserved.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
#include "snapshot/win/process_reader_win.h"
#include <windows.h>
#include <string.h>
#include "gtest/gtest.h"
#include "test/win/win_multiprocess.h"
#include "util/synchronization/semaphore.h"
#include "util/thread/thread.h"
#include "util/win/scoped_process_suspend.h"
namespace crashpad {
namespace test {
namespace {
TEST(ProcessReaderWin, SelfBasic) {
ProcessReaderWin process_reader;
ASSERT_TRUE(process_reader.Initialize(GetCurrentProcess(),
ProcessSuspensionState::kRunning));
#if !defined(ARCH_CPU_64_BITS)
EXPECT_FALSE(process_reader.Is64Bit());
#else
EXPECT_TRUE(process_reader.Is64Bit());
#endif
win: Save contents of PEB to minidump to start making !peb work This makes the basics of !peb work in windbg, however, pointed-to things are not yet retrieved. For full functionality, a variety of pointers in the PEB also needs to be walked and captured. e.g. Previously: 0:000> .ecxr eax=00000007 ebx=7e383000 ecx=c3f9a943 edx=00000000 esi=006d62d0 edi=003c9280 eip=00384828 esp=005bf634 ebp=005bf638 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246 crashy_program!crashpad::`anonymous namespace'::SomeCrashyFunction+0x28: 00384828 c7002a000000 mov dword ptr [eax],2Ah ds:002b:00000007=???????? 0:000> !peb PEB at 7e383000 error 1 InitTypeRead( nt!_PEB at 7e383000)... Now: 0:000> .ecxr eax=00000007 ebx=7f958000 ecx=02102f4d edx=00000000 esi=00e162d0 edi=01389280 eip=01344828 esp=00c2fb64 ebp=00c2fb68 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246 crashy_program!crashpad::`anonymous namespace'::SomeCrashyFunction+0x28: 01344828 c7002a000000 mov dword ptr [eax],2Ah ds:002b:00000007=???????? 0:000> !peb PEB at 7f958000 InheritedAddressSpace: No ReadImageFileExecOptions: No BeingDebugged: No ImageBaseAddress: 01340000 Ldr 77ec8b40 *** unable to read Ldr table at 77ec8b40 SubSystemData: 00000000 ProcessHeap: 00e10000 ProcessParameters: 00e114e0 CurrentDirectory: '< Name not readable >' WindowTitle: '< Name not readable >' ImageFile: '< Name not readable >' CommandLine: '< Name not readable >' DllPath: '< Name not readable >' Environment: 00000000 Unable to read Environment string. R=mark@chromium.org BUG=crashpad:46 Review URL: https://codereview.chromium.org/1364053002 .
2015-09-25 10:31:02 -07:00
EXPECT_EQ(GetCurrentProcessId(), process_reader.GetProcessInfo().ProcessID());
const char kTestMemory[] = "Some test memory";
char buffer[arraysize(kTestMemory)];
ASSERT_TRUE(
process_reader.ReadMemory(reinterpret_cast<uintptr_t>(kTestMemory),
sizeof(kTestMemory),
&buffer));
EXPECT_STREQ(kTestMemory, buffer);
}
const char kTestMemory[] = "Read me from another process";
class ProcessReaderChild final : public WinMultiprocess {
public:
ProcessReaderChild() : WinMultiprocess() {}
~ProcessReaderChild() {}
private:
void WinMultiprocessParent() override {
ProcessReaderWin process_reader;
ASSERT_TRUE(process_reader.Initialize(ChildProcess(),
ProcessSuspensionState::kRunning));
#if !defined(ARCH_CPU_64_BITS)
EXPECT_FALSE(process_reader.Is64Bit());
#else
EXPECT_TRUE(process_reader.Is64Bit());
#endif
WinVMAddress address;
Make file_io reads more rational and predictable ReadFile() attempted to continue reading after a short read. In most cases, this is fine. However, ReadFile() would keep trying to fill a partially-filled buffer until experiencing a 0-length read(), signaling end-of-file. For certain weird file descriptors like terminal input, EOF is an ephemeral condition, and attempting to read beyond EOF doesn’t actually return 0 (EOF) provided that they remain open, it will block waiting for more input. Consequently, ReadFile() and anything based on ReadFile() had an undocumented and quirky interface, which was that any short read that it returned (not an underlying short read) actually indicated EOF. This facet of ReadFile() was unexpected, so it’s being removed. The new behavior is that ReadFile() will return an underlying short read. The behavior of FileReaderInterface::Read() is updated in accordance with this change. Upon experiencing a short read, the caller can determine the best action. Most callers were already prepared for this behavior. Outside of util/file, only crashpad_database_util properly implemented EOF detection according to previous semantics, and adapting it to new semantics is trivial. Callers who require an exact-length read can use the new ReadFileExactly(), or the newly renamed LoggingReadFileExactly() or CheckedReadFileExactly(). These functions will retry following a short read. The renamed functions were previously called LoggingReadFile() and CheckedReadFile(), but those names implied that they were simply wrapping ReadFile(), which is not the case. They wrapped ReadFile() and further, insisted on a full read. Since ReadFile()’s semantics are now changing but these functions’ are not, they’re now even more distinct from ReadFile(), and must be renamed to avoid confusion. Test: * Change-Id: I06b77e0d6ad8719bd2eb67dab93a8740542dd908 Reviewed-on: https://chromium-review.googlesource.com/456676 Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 13:36:38 -04:00
CheckedReadFileExactly(ReadPipeHandle(), &address, sizeof(address));
char buffer[sizeof(kTestMemory)];
ASSERT_TRUE(
process_reader.ReadMemory(address, sizeof(kTestMemory), &buffer));
EXPECT_EQ(0, strcmp(kTestMemory, buffer));
}
void WinMultiprocessChild() override {
WinVMAddress address = reinterpret_cast<WinVMAddress>(kTestMemory);
CheckedWriteFile(WritePipeHandle(), &address, sizeof(address));
// Wait for the parent to signal that it's OK to exit by closing its end of
// the pipe.
CheckedReadFileAtEOF(ReadPipeHandle());
}
DISALLOW_COPY_AND_ASSIGN(ProcessReaderChild);
};
TEST(ProcessReaderWin, ChildBasic) {
WinMultiprocess::Run<ProcessReaderChild>();
}
TEST(ProcessReaderWin, SelfOneThread) {
ProcessReaderWin process_reader;
ASSERT_TRUE(process_reader.Initialize(GetCurrentProcess(),
ProcessSuspensionState::kRunning));
const std::vector<ProcessReaderWin::Thread>& threads =
process_reader.Threads();
// If other tests ran in this process previously, threads may have been
// created and may still be running. This check must look for at least one
// thread, not exactly one thread.
ASSERT_GE(threads.size(), 1u);
EXPECT_EQ(GetCurrentThreadId(), threads[0].id);
#if defined(ARCH_CPU_64_BITS)
EXPECT_NE(0, threads[0].context.native.Rip);
#else
EXPECT_NE(0u, threads[0].context.native.Eip);
#endif
EXPECT_EQ(0, threads[0].suspend_count);
}
class ProcessReaderChildThreadSuspendCount final : public WinMultiprocess {
public:
ProcessReaderChildThreadSuspendCount() : WinMultiprocess() {}
~ProcessReaderChildThreadSuspendCount() {}
private:
enum : unsigned int { kCreatedThreads = 3 };
class SleepingThread : public Thread {
public:
SleepingThread() : done_(nullptr) {}
void SetHandle(Semaphore* done) {
done_= done;
}
void ThreadMain() override {
done_->Wait();
};
private:
Semaphore* done_;
};
void WinMultiprocessParent() override {
char c;
Make file_io reads more rational and predictable ReadFile() attempted to continue reading after a short read. In most cases, this is fine. However, ReadFile() would keep trying to fill a partially-filled buffer until experiencing a 0-length read(), signaling end-of-file. For certain weird file descriptors like terminal input, EOF is an ephemeral condition, and attempting to read beyond EOF doesn’t actually return 0 (EOF) provided that they remain open, it will block waiting for more input. Consequently, ReadFile() and anything based on ReadFile() had an undocumented and quirky interface, which was that any short read that it returned (not an underlying short read) actually indicated EOF. This facet of ReadFile() was unexpected, so it’s being removed. The new behavior is that ReadFile() will return an underlying short read. The behavior of FileReaderInterface::Read() is updated in accordance with this change. Upon experiencing a short read, the caller can determine the best action. Most callers were already prepared for this behavior. Outside of util/file, only crashpad_database_util properly implemented EOF detection according to previous semantics, and adapting it to new semantics is trivial. Callers who require an exact-length read can use the new ReadFileExactly(), or the newly renamed LoggingReadFileExactly() or CheckedReadFileExactly(). These functions will retry following a short read. The renamed functions were previously called LoggingReadFile() and CheckedReadFile(), but those names implied that they were simply wrapping ReadFile(), which is not the case. They wrapped ReadFile() and further, insisted on a full read. Since ReadFile()’s semantics are now changing but these functions’ are not, they’re now even more distinct from ReadFile(), and must be renamed to avoid confusion. Test: * Change-Id: I06b77e0d6ad8719bd2eb67dab93a8740542dd908 Reviewed-on: https://chromium-review.googlesource.com/456676 Reviewed-by: Robert Sesek <rsesek@chromium.org>
2017-03-16 13:36:38 -04:00
CheckedReadFileExactly(ReadPipeHandle(), &c, sizeof(c));
ASSERT_EQ(' ', c);
{
ProcessReaderWin process_reader;
ASSERT_TRUE(process_reader.Initialize(ChildProcess(),
ProcessSuspensionState::kRunning));
const auto& threads = process_reader.Threads();
ASSERT_GE(threads.size(), kCreatedThreads + 1);
for (const auto& thread : threads)
EXPECT_EQ(0u, thread.suspend_count);
}
{
ScopedProcessSuspend suspend(ChildProcess());
ProcessReaderWin process_reader;
ASSERT_TRUE(process_reader.Initialize(
ChildProcess(), ProcessSuspensionState::kSuspended));
// Confirm that thread counts are adjusted correctly for the process being
// suspended.
const auto& threads = process_reader.Threads();
ASSERT_GE(threads.size(), kCreatedThreads + 1);
for (const auto& thread : threads)
EXPECT_EQ(0u, thread.suspend_count);
}
}
void WinMultiprocessChild() override {
// Create three dummy threads so we can confirm we read successfully read
// more than just the main thread.
SleepingThread threads[kCreatedThreads];
Semaphore done(0);
for (auto& thread : threads)
thread.SetHandle(&done);
for (auto& thread : threads)
thread.Start();
char c = ' ';
CheckedWriteFile(WritePipeHandle(), &c, sizeof(c));
// Wait for the parent to signal that it's OK to exit by closing its end of
// the pipe.
CheckedReadFileAtEOF(ReadPipeHandle());
for (int i = 0; i < arraysize(threads); ++i)
done.Signal();
for (auto& thread : threads)
thread.Join();
}
DISALLOW_COPY_AND_ASSIGN(ProcessReaderChildThreadSuspendCount);
};
TEST(ProcessReaderWin, ChildThreadSuspendCounts) {
WinMultiprocess::Run<ProcessReaderChildThreadSuspendCount>();
}
} // namespace
} // namespace test
} // namespace crashpad