[C++] Test failures for libarrow in conda-forge #35587
Comments
|
Hmm, arrow-flight-test and arrow-flight-transport-ucx-test also assume CUDA when UCX is enabled; we could/should perhaps try to detect when we have CUDA but no device and skip those tests. macOS seems broken in terms of Flight. Windows flight tests seem to only crash in the CUDA-enabled pipeline. Possibly the same thing as linux? |
westonpace
changed the title
h-vetinari
changed the title
|
Update for v13.0.0; looks pretty much the same as before, slightly better on windows. linux-64: osx-64: win-64: |
|
Hmm, I'm only seeing this issue, but when reporting test failures, it's more helpful to report the detailed log. You should always enable |
It's enabled in conda-forge/arrow-cpp-feedstock#1058, but I prefer not to spam 1000s of lines before people ask for more details. |
|
From here Output of
|
Well... |
|
Sure, as I said, this is from a test before minio was available. Which is the reason we're not regularly running the C++ tests in our CI (i.e. I'm talking about this issue and not #37692) |
|
Looking at the output of Looking at that file, it seems this needs the arrow/cpp/src/arrow/filesystem/gcsfs_test.cc Lines 110 to 111 in c49e242 which we don't have in conda-forge yet. I think it would make sense to skip those tests if |
The problem is that it's too easy to end up not testing GCS by mistake. Perhaps an opt-out setting somewhere? (but otherwise, perhaps can you |
|
Rebased conda-forge/arrow-cpp-feedstock#1058 on arrow 14 and added minio. Still failing a couple tests, here for linux:
which -- based on the values -- kinda looks like it's a question of leap seconds being applied or not (though the -0117 "time zone" looks very weird too). Not sure if this needs a newer linux distro than we're running...? While This might be related to the fact that we only have a newer minio in conda-forge than what arrow uses (see #37692). Though I also see so it could be something related to not having some AWS dummy account somewhere to perform operations on? There's more errors on the CUDA builds (which presumably try to look for a GPU and fail), but that's not the first priority now. On OSX, we get: In particular, the On windows, we have more failures: Here's a link to the CI run. |
|
Update for 16.1 (logs), I was quite stunned that the test suite passes on windows. 🥳 On linux: On osx: The and the s3fs tests fail because they expect failure which doesn't happen: The utility failure is - as above - related to some timestamp difference (missing leapseconds?) and the flight error is: |
|
The Azure test failures can be ignored too because the Azure test require https://github.com/Azure/Azurite . |
|
Update for arrow 17.0: linux-64osx-64win-64passes 🥳 I got rid of the failures in specifically The remaining error (linux-only) in which feels like a corner case as well. All in all, I think we're getting kinda close in activating this in the feedstock. Any thoughts on that? @kou @pitrou @raulcd @assignUser @jorisvandenbossche |
|
Does it use musl as libc? |
|
No, we don't support musl as a target, everything is glibc (though relatively old by default; 2.17). |
|
Hmm. Could you share the CI log URL for the |
|
Sure: logs |
|
Thanks. It seems that |
The test passes on an alma8 image with glibc 2.28 (logs) |
|
Thanks. It seems that |
|
I updated conda-forge/arrow-cpp-feedstock#1058 for v18, opened a PR for the failure of In more detail: (this is potentially due to #44621, as I haven't seen it before) The more serious one is the flight test, which just crashes/aborts |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug, including details regarding any error messages, version, and platform.
As I explain in conda-forge/arrow-cpp-feedstock#1058, I wanted to enable the gtest suite for
libarrow. The result is as follows:linux-64:
osx-64:
win-64:
The
arrow-cuda-testfailure is probably unavoidable (as we have no CUDA drivers in CI), but the others shouldn't have to fail AFAICT.More detailed logs can be found here
Component(s)
C++, Packaging
The text was updated successfully, but these errors were encountered: