FindAvailableMemoryRange can currently overwrite existing memory (by restricting the VM below addresses that are already used). This patch adds a check to make sure we don't restrict the VM space too much. We are also now more explicit about why the lookup failed and print out verbose values.
Details
- Reviewers
delcypher kcc george.karpenkov eugenis filcab fjricci - Commits
- rG061f3589ccae: [asan] Be more careful and verbose when allocating dynamic shadow memory
rCRT326106: [asan] Be more careful and verbose when allocating dynamic shadow memory
rL326106: [asan] Be more careful and verbose when allocating dynamic shadow memory
Diff Detail
Event Timeline
lib/asan/asan_mac.cc | ||
---|---|---|
66 | yay logging yay! | |
75 | I don't quite understand semantics here. | |
lib/sanitizer_common/sanitizer_mac.cc | ||
901 | Is this assignment necessary? Maximum size is zero unless set otherwise? |
lib/asan/asan_mac.cc | ||
---|---|---|
75 | max_occupied_vm is the largest address that it already occupied by something. We're trying to restrict the VM space with new_max_vm being the new VM limit. This check is to make sure we don't restrict too much (which would overwrite memory that is already used). Suggestions for better name of max_occupied_vm? | |
lib/sanitizer_common/sanitizer_mac.cc | ||
901 | I'd rather not leave garbage in max_vm_address if for some reason the loop below doesn't find any regions at all. |
lib/sanitizer_common/sanitizer_mac.cc | ||
---|---|---|
901 | I mean, I don't want the semantics of this (or any) function to only partially (on some paths) initialize pointer-passed values... |
lib/asan/asan_mac.cc | ||
---|---|---|
75 | largest_occupied_vm? Almost the same, but at least to me does quite have same connotation, but that's a not important nit.. In any case, maybe this should be explained in a doxygen comment for FindAvailableMemoryRange? |
lib/asan/asan_mac.cc | ||
---|---|---|
75 | max_occupied_addr or max_occupied_vm_addr, perhaps? |
yay logging yay!