Update asan-known-issues.md #5340
Conversation
zacklj89
commented
May 21, 2025
zacklj89
commented
- Remove Win10 reference, as we're always targeting the latest Windows release with ASan
- Add known issues bit about unloading DLLs causing issues
- Remove Win10 reference - Add known issues bit about unloading DLLs
|
@zacklj89 : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. |
|
Learn Build status updates of commit e924f9a:
|
| File | Status | Preview URL | Details |
|---|---|---|---|
| docs/sanitizers/asan-known-issues.md | Details |
docs/sanitizers/asan-known-issues.md
- Line 86, Column 140: [Warning: hard-coded-locale - See documentation]
Link 'https://learn.microsoft.com/en-us/windows-hardware/drivers/taef/' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites. - Line 86, Column 140: [Suggestion: docs-link-absolute - See documentation]
Absolute link 'https://learn.microsoft.com/en-us/windows-hardware/drivers/taef/' will be broken in isolated environments. Replace with a relative link.
For more details, please refer to the build report.
Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:
- Try searching the learn.microsoft.com contributor guides
- Post your question in the Learn support channel
| @@ -82,6 +79,14 @@ As a workaround, create a *`Directory.Build.props`* file in the root of your pro | |||
|
|
|||
| Thread local variables (global variables declared with `__declspec(thread)` or `thread_local`) aren't protected by AddressSanitizer. This limitation isn't specific to Windows or Microsoft Visual C++, but is a general limitation. | |||
|
|
|||
| ## Loading and unloading DLLs | |||
There was a problem hiding this comment.
I'm partial to this alternative title.
| ## Loading and unloading DLLs | |
| ## Issues with partially sanitized executables. |
After all, the issue is not with loading and unloading dlls per-se, but instead with the partial /fsanitize across components. What do you think?
There was a problem hiding this comment.
@TylerMSFT Can you respond to the comment above?
There was a problem hiding this comment.
This isn't my article. @zacklj89 is writing it.
My 2c is I like the suggested change.
There was a problem hiding this comment.
@TylerMSFT Whoops, sorry about that!
@zacklj89 Could you respond to the comment above?
docs/sanitizers/asan-known-issues.md
Outdated
| @@ -82,6 +79,14 @@ As a workaround, create a *`Directory.Build.props`* file in the root of your pro | |||
|
|
|||
| Thread local variables (global variables declared with `__declspec(thread)` or `thread_local`) aren't protected by AddressSanitizer. This limitation isn't specific to Windows or Microsoft Visual C++, but is a general limitation. | |||
|
|
|||
| ## Loading and unloading DLLs | |||
|
|
|||
| If the entire process is not compiled with `/fsanitize=address`, there may be limitations in ASan's ability to diagnose memory safety errors. The most common example is when a DLL is compiled with ASan and loaded into a process that **was not** compiled with ASan. In this case, ASan will attempt to categorize allocations that took place prior to ASan initialization. If those allocations are transformed in any way (reallocated, moved, etc.), ASan will then attempt to own and monitor the lifetime and memory loads/stores. | |||
There was a problem hiding this comment.
nit: I think we can be a bit more assertive in the opening sentence:
| If the entire process is not compiled with `/fsanitize=address`, there may be limitations in ASan's ability to diagnose memory safety errors. The most common example is when a DLL is compiled with ASan and loaded into a process that **was not** compiled with ASan. In this case, ASan will attempt to categorize allocations that took place prior to ASan initialization. If those allocations are transformed in any way (reallocated, moved, etc.), ASan will then attempt to own and monitor the lifetime and memory loads/stores. | |
| ASan's analysis is limited when executing alongside binaries that were not complied with `/fsanitize=address`. For example, this would occur if an executable compiled _without_ `/fsanitize=address` loads an ASan-instrumented `.dll`. | |
| In this case, ASan coverage over allocations that took place prior to ASan initialization is best-effort. If those allocations are transformed in any way (reallocated, moved, etc.), ASan will then attempt to own and monitor their lifetime and accesses moving forward. |
docs/sanitizers/asan-known-issues.md
Outdated
|
|
||
| If the entire process is not compiled with `/fsanitize=address`, there may be limitations in ASan's ability to diagnose memory safety errors. The most common example is when a DLL is compiled with ASan and loaded into a process that **was not** compiled with ASan. In this case, ASan will attempt to categorize allocations that took place prior to ASan initialization. If those allocations are transformed in any way (reallocated, moved, etc.), ASan will then attempt to own and monitor the lifetime and memory loads/stores. | ||
|
|
||
| In the event that all DLLs compiled with ASan leave the process before the end of its execution (like in the event of test drivers such as [TAEF](https://learn.microsoft.com/en-us/windows-hardware/drivers/taef/)), there may dangling references to intercepted functions (`memcmp`, `memcpy`, `memmove`, etc.), and may result in crashes. This is a current limitation with these configurations and unloading DLLs. |
There was a problem hiding this comment.
in this case, I think the TAEF reference may be removed, unless we think we'll get more TAEF reports in the future. I don't feel strongly, but given that it's mostly an internal tool, I'm unsure if there's much value in referencing it externally.
There was a problem hiding this comment.
This is a current limitation with these configurations and unloading DLLs.
Is this a limitation of TAEF, or our own. I feel like there's little we could do to improve this, or is there?
edit pass
|
Learn Build status updates of commit ab00c49:
|
| File | Status | Preview URL | Details |
|---|---|---|---|
| docs/sanitizers/asan-known-issues.md | Details |
docs/sanitizers/asan-known-issues.md
- Line 86, Column 145: [Warning: hard-coded-locale - See documentation]
Link 'https://learn.microsoft.com/en-us/windows-hardware/drivers/taef/' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites. - Line 86, Column 145: [Suggestion: docs-link-absolute - See documentation]
Absolute link 'https://learn.microsoft.com/en-us/windows-hardware/drivers/taef/' will be broken in isolated environments. Replace with a relative link.
For more details, please refer to the build report.
Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:
- Try searching the learn.microsoft.com contributor guides
- Post your question in the Learn support channel
|
Learn Build status updates of commit fab571c: ✅ Validation status: passed
For more details, please refer to the build report. For any questions, please:
|
PRMerger Results
|
|
Can you review the proposed changes? Important: When the changes are ready for publication, adding a #label:"aq-pr-triaged" |
prmerger-automator
bot
added
the
aq-pr-triaged
