Change Details

This teaches lldb-test how to launch a process, set up an IRMemoryMap, and issue memory allocations in the target process through the map. This makes it possible to test IRMemoryMap in a targeted way. The main motivation for testing IRMemoryMap is to uncover bugs. I've noticed two so far. The first bug is that IRMemoryMap::Malloc performs an adjustment on the pointer returned from Process::AllocateMemory (for alignment purposes) which ultimately allows overlapping memory regions to be created. The second bug is that after most of the address space on the host side is exhausted, Malloc may return the same address multiple times. These bugs (and hopefully more!) can be uncovered and tested for with targeted lldb-test commands. At an even higher level, the motivation for addressing bugs in IRMemoryMap::Malloc is that they can lead to strange user-visible failures (e.g, variables assume the wrong value during expression evaluation, or the debugger crashes). See my third comment on this [[ https://github.com/apple/swift-lldb/pull/652 | swift-lldb PR ]] for an example: I hope lldb-test is the right place to test IRMemoryMap. Setting up a gtest-style unit test proved too cumbersome (you need to recreate or mock way too much debugger state), as did writing end-to-end tests (it's hard to write a test that actually hits a buggy path). With lldb-test, it's easy to read/generate the test input and parse the test output. I'll attach a simple "fuzz" tester which generates failing test cases with ease. {F6288839} Here's an example: ``` Command: malloc(size=1024, alignment=32) Malloc: address = 0xca000 Command: malloc(size=64, alignment=16) Malloc: address = 0xca400 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca440 Command: malloc(size=16, alignment=8) Malloc: address = 0xca840 Command: malloc(size=2048, alignment=16) Malloc: address = 0xcb000 Command: malloc(size=64, alignment=32) Malloc: address = 0xca860 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca890 Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0) ```

This teaches lldb-test how to launch a process, set up an IRMemoryMap, and issue memory allocations in the target process through the map. This makes it possible to test IRMemoryMap in a targeted way. This has uncovered two bugs so far. The first bug is that Malloc performs an adjustment on the pointer returned from AllocateMemory (for alignment purposes) which ultimately allows overlapping memory regions to be created. The second bug is that after most of the address space on the host side is exhausted, Malloc may return the same address multiple times. These bugs (and hopefully more!) can be uncovered and tested for with targeted lldb-test commands. At an even higher level, the motivation for addressing these bugs is that they can lead to strange user-visible failures (e.g, variables assume the wrong value during expression evaluation, or the debugger crashes). See my third comment on this swift-lldb PR for an example: https://github.com/apple/swift-lldb/pull/652 I hope lldb-test is the right place to add this testing harness. Setting up a gtest-style unit test proved too cumbersome (you need to recreate or mock way too much debugger state), as did writing end-to-end tests (it's hard to write a test that actually hits a buggy path). With lldb-test, it's easy to read/generate the test input and parse the test output. I'll attach a simple "fuzz" tester which generates failing test cases to the Phab review. Here's an example: ``` Command: malloc(size=1024, alignment=32) Malloc: address = 0xca000 Command: malloc(size=64, alignment=16) Malloc: address = 0xca400 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca440 Command: malloc(size=16, alignment=8) Malloc: address = 0xca840 Command: malloc(size=2048, alignment=16) Malloc: address = 0xcb000 Command: malloc(size=64, alignment=32) Malloc: address = 0xca860 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca890 Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0) ``` {F6288839}

This teaches lldb-test how to launch a process, set up an IRMemoryMap, and issue memory allocations in the target process through the map. This makes it possible to test IRMemoryMap in a targeted way. The main motivation for testing IRMemoryMap is to uncover bugsThis has uncovered two bugs so far. I'veThe first bug is that Malloc noticed two so far. The first bug is that IRMemoryMap::Malloc performs an adjustment on the pointer returned from Process::AllocateMemory (for alignment purposes) which ultimately allows overlapping memory regions to be created. The second bug is that after most of the address space on the host side is exhausted, Malloc may return the same address multiple times. These bugs (and hopefully more!) can be uncovered and tested for with targeted lldb-test commands. At an even higher level, the motivation for addressing bugs in IRMemoryMap::Malloc is that they can lead to strange user-visiblethese bugs is that they can lead to strange user-visible failures (e.g, variables assume the wrong value during expression evaluation, or the debugger crashes).assume the wrong value during expression evaluation, See my third comment on thisor the debugger [[ https://github.com/apple/swift-lldb/pull/652 |crashes). See my third comment on this swift-lldb PR ]] for an example: https://github.com/apple/swift-lldb/pull/652 I hope lldb-test is the right place to test IRMemoryMapadd this testing harness. Setting up a up a gtest-style unit test proved too cumbersome (you need to recreate or or mock way too much debugger state), as did writing end-to-end tests (it's (it's hard to write a test that actually hits a buggy path). With lldb-test, it's easy to read/generate the test input and parse the test output. I'll attach a simple "fuzz" tester which generates failing test test cases with ease. {F6288839}to the Phab review. Here's an example: Here's an example: ``` Command: malloc(size=1024, alignment=32) Malloc: address = 0xca000 Command: malloc(size=64, alignment=16) Malloc: address = 0xca400 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca440 Command: malloc(size=16, alignment=8) Malloc: address = 0xca840 Command: malloc(size=2048, alignment=16) Malloc: address = 0xcb000 Command: malloc(size=64, alignment=32) Malloc: address = 0xca860 Command: malloc(size=1024, alignment=16) Malloc: address = 0xca890 Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0) ``` {F6288839}