-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider debug mode for ArrayPool #7532
Comments
cc @stephentoub |
Requiring a different build of the runtime to do this is non-starter. This would need to be enabled dynamically with a config switch or environment variable. Similar to how malloc/free diagnostic works in C++ today (pageheap on Windows, |
Oh - it's right in front of my nose in PinnableBufferCache already. Just another one.
|
Another option would be a different factory method to create the ArrayPool (perhaps overloads or instead of Shared() or Create()) that would return the diagnostic pool. Presumably there are relatively few places in one's code where the array pool is created (probably 1, if you know which array pool is leading to the problem) so changing that one line of code for testing purposes is not onerous. As a separate concrete implementation of ArrayPool performance would not be a concern and it could record callstacks, etc like a diagnostic heap. |
Can this be achieved with AppContext switch? Since the checks may be somehow intensive, I'm not sure about Tier-0 performance impact. |
There are several ways to misuse array pool
There is some logging to help trace suspected cases of 1 and 2.
For 4 if we start caring more about that someday we could change the default to clear data.
For 5 we could at least (in a diagnostic mode) compare against existing arrays in the pool (perhaps an expanded size pool that returns LRU so it's likely still in the pool when returned the 2nd time)
We could help catch cases of both 2 and 3 by having a mode where we set the array to 0xDEADBEEF on return. We would do this whether or not the returner requested the array clear, because the next renter cannot rely on the returner.
This should be enabled in #if DEBUG but since running chk corelib is so rarely done, it might realistically only get used if it was #if DEBUG || DEBUG_ARRAYPOOL or something like that. So perhaps this isn't worth bothering with unless and until we have some investigation that it would help with.
Just a thought for the future.
The text was updated successfully, but these errors were encountered: