[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 |
kou
added a commit
that referenced
this issue
Nov 15, 2024
) ### Rationale for this change Enable tests for libarrow in conda-forge: #35587 ### What changes are included in this PR? old glibc does not actually support timezones like `-0117` (used in `StrptimeZoneOffset` test). The exact lower bound for glibc is hard for me to determine; I know that it passes with 2.28 and that it fails with 2.17. Anything in between is an open question. I went with the conservative option here. ### Are these changes tested? Tested in conda-forge/arrow-cpp-feedstock#1058 ### Are there any user-facing changes? * GitHub Issue: #43808 Lead-authored-by: H. Vetinari <[email protected]> Co-authored-by: Sutou Kouhei <[email protected]> Signed-off-by: Sutou Kouhei <[email protected]>
|
Alright, with the backport of #44621, we're getting very close to enabling the tests in conda-forge 🥳 - linux is now passing too, but there's now a new failure on osx that won't go away even after multiple restarts: This doesn't look like a serious failure to me, in the sense that I can skip that one if desired, or does someone know of another way to fix this? |
|
Well, we've tried several times to run the C++ S3 tests on macOS, but have for now bumped into issues we weren't able to diagnose: see #40410 and #44211 Interestingly, the PyArrow tests with S3 run fine. You could perhaps try disabling the nonexistent bucket tests on macOS and see if that gets macOS CI to pass reliably on conda-forge. |
|
Oh and about:
Our async Flight support is unfortunately finicky, and noone is working on it anymore. So, yeah, there are sporadic failures on those tests... |
|
Closing this since we've enabled this in conda-forge for a while now (since conda-forge/arrow-cpp-feedstock#1058). |
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: