[I] bug(services/hf): Java HF blocking behavior tests segfault after XET write path changes [opendal]

["Xuanwo (via GitHub)" <gi...@apache.org>]

Xuanwo opened a new issue, #7367:
URL: https://github.com/apache/opendal/issues/7367

   ### Describe the bug
   
   After `feat(hf): support writing and reading from both http and xet` was merged into `main` (`8d3dbcc3ef6a38a3ed2a6610cf826ef51dbe9013`, PR #7185), the Java HF behavior tests started crashing the forked JVM instead of returning a normal test failure.
   
   The current failure on `main` is:
   - `binding_java / ubuntu-latest / hf / hf_bucket`
   - run: https://github.com/apache/opendal/actions/runs/24129553750/job/70402985065
   
   The relevant log ends with:
   
   ```text
   [INFO] Running org.apache.opendal.test.behavior.BlockingWriteTest
   Test BlockingWriteTest(hf) is running.
   Segmentation fault (core dumped)
   [ERROR] Process Exit Code: 139
   [ERROR] Crashed tests:
   [ERROR] org.apache.opendal.test.behavior.BlockingWriteTest
   ```
   
   This does not look like a normal Java binding assertion failure. The JVM is being terminated by native code.
   
   There is also evidence that this regression existed before merge: PR #7185 itself had a failing Java HF check:
   - `binding_java / ubuntu-latest / hf / huggingface`
   - job: https://github.com/apache/opendal/actions/runs/24038490730/job/70103988178
   
   That earlier job also ended with `Segmentation fault (core dumped)` while running HF Java behavior tests.
   
   ### Steps to Reproduce
   
   1. Check out `main` at `8d3dbcc3ef6a38a3ed2a6610cf826ef51dbe9013` or later.
   2. Run the Java behavior tests against an HF config with write capability enabled.
   3. Exercise the blocking operator path used by the Java behavior tests.
   4. Observe that the JVM crashes with `SIGSEGV` / exit code `139` instead of surfacing a normal exception.
   
   From the current CI logs, the crash happens after the test suite constructs a blocking operator from an async operator and enters `BlockingWriteTest`.
   
   ### Expected Behavior
   
   HF behavior tests should either pass or fail with a normal Rust/Java exception. They must not crash the JVM.
   
   ### Additional Context
   
   A few details that make this look related to the new HF/XET write path instead of the Java test logic itself:
   
   - `BehaviorExtension` creates the Java blocking operator via `this.asyncOperator.blocking()`.
   - The crash on `main` happens inside `BlockingWriteTest` when `op().write(path, content)` is called.
   - The HF writer now always goes through the XET upload path introduced in PR #7185.
   - Async HF Java tests run before the crash, which suggests the regression is specific to the blocking/native interaction.
   
   Relevant code paths:
   
   - `bindings/java/src/test/java/org/apache/opendal/test/behavior/BehaviorExtension.java`
   - `bindings/java/src/test/java/org/apache/opendal/test/behavior/BlockingWriteTest.java`
   - `bindings/java/src/async_operator.rs`
   - `bindings/java/src/operator.rs`
   - `core/services/hf/src/writer.rs`
   
   Likely area to investigate first: the interaction between the Java blocking binding path and the new HF/XET session-managed write implementation.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@opendal.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] bug(bindings/java): HF blocking path segfaults on Linux with XET async upload [opendal]

["Xuanwo (via GitHub)" <gi...@apache.org>]

Xuanwo closed issue #7367: bug(bindings/java): HF blocking path segfaults on Linux with XET async upload
URL: https://github.com/apache/opendal/issues/7367


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@opendal.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org