-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
malloc issue with polyfit #12230
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
Comments
I'd be very surprised if this was a NumPy problem, we don't see any problems with our mac tests. How did you install? |
@charris - I just did |
There is a bug here in the error reporting - if Bisecting will probably lead you to #9980, which added that |
Any idea how that works? Where does it get the source? You can find compiled development wheels at https://7933911d6844c6c53a7d-47bd50c35cd79bd838daf386af554a83.ssl.cf2.rackcdn.com/ |
@charris - I just git cloned the repository and did |
This is the function that's failing: numpy/numpy/linalg/umath_linalg.c.src Lines 2991 to 3076 in 3ef55be
My guess is that your numpy/numpy/linalg/umath_linalg.c.src Lines 3037 to 3058 in 3ef55be
Lapack 3.2.1 and older exhibit a bug where they do not actually report the workspace query. Perhaps we need to detect that and throw an exception telling users to use a non-broken lapack. |
We've seen this issue before & it has been reported on Macports & I discussed with Eric a bit too. We disable acceleration in our CI at the moment. |
Just in case it's helpful, I'm currently working in a conda environment with:
|
By that , you mean the mac "Accelerate" library |
I mean we aggressively disable as many linalg-accelerating things as we can for the mac CI testing on Azure at the moment:
Should perhaps try to replicate what we do for wheels -- I think Stefan said that using openblas v. something. |
I ran
|
The commit in question may have exposed an already-existing error state that previously was discarded. Could you try compiling without the buggy lapack library as our CI currently does? |
@mattip - what is the best way to compile without the buggy lapack? |
setting all the environment variables listed in the comment above to None will disable third-party libraries and compile using a local implementation of the lapack routines (lapack-lite). So using |
running with valgrind on a minimal testcase could also help finding where the broken memory handling is. |
does mac have the madvise MADV_HUGEPAGES flag? check the file that was a recent change to memory handling in the master branch, though it shouldn't be the cause. |
Compiling with the flags @mattip suggested works fine. I'd be happy to use valgrind on my failing example - what is the proper valgrind incantation? (I'm not too familiar with it) There is no |
|
|
@pv - I had a buggy version of
Does this help? |
thanks it seems to confirm that the lapack workspace queries do not work |
Any progress on a fix for this? I plan on releasing 1.15.4 about Nov 4. ISTR that we once had some workspace computation workarounds. |
Pushing off to 1.17. |
Any reason not to close this? It doesn't seem to be a NumPy problem. |
I tried installing the latest developer version of numpy today and am running into an error related to memory allocation when running
polyfit
.Reproducing code example:
Numpy/Python version information:
Platform: MacOS 10.13.6
Python:
Numpy:
2be1544
The text was updated successfully, but these errors were encountered: