Cherry pick rdar://problem/58789439 part3 #1095
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…is called during the LateInitialize stage of the sanitizer runtimes. Summary: This is implemented by adding a `Symbolizer::LateInitializeTools()` method that iterates over the registered tools and calls the `LateInitialize()` method on them. `Symbolizer::LateInitializeTools()` is now called from the various `Symbolizer::LateInitialize()` implementations. The default implementation of `SymbolizerTool::LateInitialize()` does nothing so this change should be NFC. This change allows `SymbolizerTool` implementations to perform any initialization that they need to perform at the LateInitialize stage of a sanitizer runtime init. rdar://problem/58789439 Reviewers: kubamracek, yln, vitalybuka, cryptoad, phosek, rnk Subscribers: #sanitizers, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D78178 (cherry picked from commit fccea7f)
Summary: Due to sandbox restrictions in the recent versions of the simulator runtime the atos program is no longer able to access the task port of a parent process without additional help. This patch fixes this by registering a task port for the parent process before spawning atos and also tells atos to look for this by setting a special environment variable. This patch is based on an Apple internal fix (rdar://problem/43693565) that unfortunately contained a bug (rdar://problem/58789439) because it used setenv() to set the special environment variable. This is not safe because in certain circumstances this can trigger a call to realloc() which can fail during symbolization leading to deadlock. A test case is included that captures this problem. The approach used to set the necessary environment variable is as follows: 1. Calling `putenv()` early during process init (but late enough that malloc/realloc works) to set a dummy value for the environment variable. 2. Just before `atos` is spawned the storage for the environment variable is modified to contain the correct PID. A flaw with this approach is that if the application messes with the atos environment variable (i.e. unsets it or changes it) between the time its set and the time we need it then symbolization will fail. We will ignore this issue for now but a `DCHECK()` is included in the patch that documents this assumption but doesn't check it at runtime to avoid calling `getenv()`. The issue reported in rdar://problem/58789439 manifested as a deadlock during symbolization in the following situation: 1. Before TSan detects an issue something outside of the runtime calls setenv() that sets a new environment variable that wasn't previously set. This triggers a call to malloc() to allocate a new environment array. This uses TSan's normal user-facing allocator. LibC stores this pointer for future use later. 2. TSan detects an issue and tries to launch the symbolizer. When we are in the symbolizer we switch to a different (internal allocator) and then we call setenv() to set a new environment variable. When this happen setenv() sees that it needs to make the environment array larger and calls realloc() on the existing enviroment array because it remembers that it previously allocated memory for it. Calling realloc() fails here because it is being called on a pointer its never seen before. The included test case closely reproduces the originally reported problem but it doesn't replicate the `((kBlockMagic)) == ((((u64*)addr)[0])` assertion failure exactly. This is due to the way TSan's normal allocator allocates the environment array the first time it is allocated. In the test program addr[0] accesses an inaccessible page and raises SIGBUS. If TSan's SIGBUS signal handler is active, the signal is caught and symbolication is attempted again which results in deadlock. In the originally reported problem the pointer is successfully derefenced but then the assert fails due to the provided pointer not coming from the active allocator. When the assert fails TSan tries to symbolicate the stacktrace while already being in the middle of symbolication which results in deadlock. rdar://problem/58789439 Reviewers: kubamracek, yln Subscribers: jfb, #sanitizers, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D78179 (cherry picked from commit 861b69f)
|
@swift-ci please test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.