-
-
Notifications
You must be signed in to change notification settings - Fork 32.6k
bpo-40928 osx malloc real fix #26786
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
bpo-40928 osx malloc real fix #26786
Conversation
* When trying to allocate very large regions on OS X, malloc does not fail silently. It sends a very noisy error out to STDERR * This provides a helper function to warn the user, and provides the warning for test_decimal, which consistently generates these warnings on my mac.
* This prevents Apple's libc from sending messages to STDERR.
|
This PR is stale because it has been open for 30 days with no activity. |
|
What I don't like about this is that it will slow down all legit allocations to protect against stderr warnings for humongous allocations. Seems like a tough compromise. |
|
@ambv I got these results from the test-suite-as-a-benchmark approach:
So, based on this rough test, it seems like the performance implications are very small. I don't know whether this is a reliable or valid metric, though. By the way, in all cases, I ran the tests like this: ./python.exe -m test -j8Edit: and, I am on a macOS system, so the change does apply! |
|
ASAN failure is real, possibly this use case needs some build configuration adjustment. Currently reports: |
|
I still feel like modifying malloc just to appease chatty diagnostics in super-unlikely conditions is not the right way to go about this, even if the perf cost is minimal in your benchmarks. Since this problem is isolated to test_decimal, I went with your string notice patch instead (GH-26783). |
Blocking any allocation call greater than 4TB prevents warnings appearing in STDERR on OS X.
https://bugs.python.org/issue40928