-
-
Notifications
You must be signed in to change notification settings - Fork 36
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
build 1.8.0 #198
build 1.8.0 #198
Conversation
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
I updated the import tests in light of scipy/scipy#14360. All the previously tested underscore-less imports are mentioned under |
There seems to be a segfault with the windows builds regarding PROPACK, and it's not ameliorated by moving to vs2019.
I don't have time to investigate this right now, but wanted to let you know. |
I don't remember segfaults while working with PROPACK. Do you, @mckib2? |
No, I these segfaults look like a new development to me. I'm hobbled on Windows right now (can't figure out how to build scipy), but I'll try again this evening to see if I can move the needle. Are there updates to the existing Windows build guide we're aware of that just haven't been written up yet? |
This seems very related: #15108 These jobs are using conda-forge which looks like it doesn't use OpenBLAS |
OK, the bug seems to be related to blas/lapack, and more specifically, involving MKL. In particular, this combination
failed, while the reference lapack works:
I'll check if the issue also appears with openblas, but since MKL is the default in conda-forge for windows, this definitely needs fixing, IMO. |
The segfault also appears with openblas, but - interestingly - not with blis. |
From the CI failures, it looks like only builds on Windows fail? I've been at it for hours again and still haven't been able to resurrect my Windows build, so I'm not sure what kind of help I can be until I get this sorted on my end |
Yes, it's only windows. Actually, even more specifically - only with the OpenBLAS or MKL flavours of blas/lapack; Netlib & Blis don't run into the same issues for some reason. |
New segfault on osx64, but only for python 3.10. Haven't verified all that has changed in the last 2 days, but at least pythran 0.11 got released, which might be a hint?
|
There is no Pythran usage in |
@martin-frbg, maybe you could opine here? There's a segfault in the new scipy release with openblas (also happens for MKL), but not with netlib. The segfault occurs in the test suite, but the following is enough to trigger very likely the same problem on my windows machine (using the artefacts from this PR**; adapted from here):
** to use the build from this PR, download the artefact, unzip it, then unzip it again, and once you have a folder containing
|
At this point, we don't know if it is the same issue as the crashes encountered here, but the seg. fault that I reported in scipy/scipy#15108 is on Linux. I get the seg. fault when I build SciPy with conda-installed numpy (so it gets MKL), but not when I pip-install everything (which uses OpenBLAS). In my few experiments, the crashes only occurred with complex input. If that is the case in general, a pragmatic work-around might be to disallow complex input when the PROPACK method is used in SciPy 1.8.0, and see if the problem with complex input can be fixed for 1.8.1. |
Any chance to see a backtrace (faulthandler.py or whatever) - I am not too keen to install the whole thing, conda and all on Windows right now. |
One thing I'd appreciate here is a quick ping letting me know if, in your opinion, I should delay the release of the next SciPy release candidate (scheduled Monday December 20th, tentatively) based on the observations here? Or if we should continue approximately on that schedule but likely consider an rc3. |
Not much info I'm afraid...
|
Going to spin up a VM and try to replicate the issue and get a backtrace. I'll let you know hopefully by the end of tonight what I opinion is |
I tried running this with the Propack PR mentioned in scipy/scipy#15108, but the segfault persists. |
Currently, the status is "unreleaseable" from the conda-forge side. Unfortunately it's unclear so far what's causing the issue, resp. what the fix would be. However, it's not like the scipy release needs to wait for conda-forge. More specifically to your question, I think more RCs is good - i.e. release rc2 soon, and keep rc3 as an option - I see some propack-changes in the rc2-PR, and as soon as there's a tag, I'll get it tested. Bringing in accumulated changes will hopefully help chip away at the problem. |
Assuming this is an MKL issue and not Windows error, I left an update here on current progress at resolving these segfaults. What I've found is all the changes I've tested in scipy/PROPACK#1 are good (I want to test out all of them out with something other than MKL and get the present issues resolved before I approve and merge) and a simple macro definition seems to solve complex64 issues completely. I have not attempted a Windows build again, but I will put up a PR with my edits in case someone wants to try to make sure the fixes are seen there as well |
So far it only appears on windows (and not just MKL, but also openblas), so I think it definitely is at least somewhat of a windows issue. In any case, I've now also added testing of linux/osx against the various blas flavours - then we'll see if it appears for MKL on other platforms as well. Given that you mention |
I was doing all testing on Linux, so if complex128 data-types are an issue, it's a cross-platform one |
So MKL also segfaults on osx, but not on linux, where it's "merely" a single test failure. The matrix (for x64 only) is:
|
weird. I would have hoped to see which BLAS or LAPACK function is failing. Right now it is not even certain that MKL and OpenBLAS hit the same problem. What I can say for OpenBLAS is that 0.3.18 has a potential out-of bounds access bug in ?TRSV which could be on the code path of the SVD algorithm you (or Eigen) use - I am about to release 0.3.19. |
thanks @h-vetinari! |
fyi, I pushed up the |
…nda-forge-pinning 2022.02.03.19.17.39
I'm ready to push the merge button any time. From then on, it takes about ~3h until the packages become installable. |
OK, given that I see the wheels on the GH release page, I think there's no need to wait anymore. |
More submodules! 🙃