-
Notifications
You must be signed in to change notification settings - Fork 72
Prevent JVM Segfault #294
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
Prevent JVM Segfault #294
Conversation
Codecov Report
@@ Coverage Diff @@
## main #294 +/- ##
==========================================
- Coverage 95.99% 95.89% -0.11%
==========================================
Files 64 65 +1
Lines 2797 2800 +3
Branches 421 418 -3
==========================================
Hits 2685 2685
- Misses 71 73 +2
- Partials 41 42 +1
Continue to review full report at Codecov.
|
|
I plan to add a pytest with some of the common occurrences where we were seeing the segfault occur so we can guard against those in the future. I'm just compiling that list offline but will post a pytest in the coming days. |
|
rerun tests |
|
Cool, looks like this triggers the segfault! Is there any way we can wrap this up in a GPU-only test? |
I think it is actually failing to find |
|
Checking the gpuCI run, it looks like dask-cuda is there in the conda list step, so I'm assuming it being imported after Would we need to add dask-cuda to the host test requirements, or is there a way to contain the conditions for this segfault (i.e. the dask-cuda import) in a test that can be disabled on host? |
Under certain circumstances importing
dask_cudaafter anydask_sqlimports will cause an underlying segfault to be triggered in the JVM. In tests thus far adjusting that import order incontext.pyprevents that from happening. Subsequent PRs may be required after further testing.