LuciferYang opened a new pull request, #12402:
URL: https://github.com/apache/gluten/pull/12402
### What changes were proposed in this pull request?
`JniLibLoader.toRealPath()` previously walked symbolic links with a
hand-rolled loop that called `Files.readSymbolicLink` and fed the *stored*
(often relative) target back into `Paths.get(...)`. That resolved relative
targets against the process working directory instead of the link's own parent,
and the loop had no cycle guard. This PR rewrites the method to delegate to
`Path#toRealPath` so symlink-chain resolution (including `.`/`..`
normalisation) and cycle detection (`FileSystemLoopException` on Linux;
`FileSystemException` carrying "Too many levels of symbolic links" on current
openjdk macOS) are handled by the JDK. Visibility is widened from `private` to
package-private so a unit test in the same package can call it directly. The
caught type is `Exception` (not `Throwable`), wrapping
`IOException`/`InvalidPathException`/`SecurityException`/`NullPointerException`
as `GlutenException` while intentionally letting `Error` subclasses propagate.
A JUnit 4 test covers a plain regul
ar file (canonicalisation via a symlinked parent dir, so the assertion bites
on Linux too), a versioned-library symlink chain with relative targets, and a
2-cycle. A `@Before` probe skips cleanly on filesystems that do not support
symbolic-link creation or resolution.
### Why are the changes needed?
Closes #12401. Versioned native libraries are typically published as a chain
like `libfoo.so -> libfoo.so.1 -> libfoo.so.1.2.3`, where the stored target of
`libfoo.so` is the *relative* `libfoo.so.1`. The old loop's second iteration
called `Files.isSymbolicLink(Paths.get("libfoo.so.1"))`, which probes the JVM's
working directory instead of the directory holding the link, so resolution
silently returned a wrong path that `System.load` then rejected (or, if the
working directory happened to contain a matching name, loaded the wrong
library). A symlink cycle would also spin forever inside the loop.
`Path#toRealPath` removes both issues with a single JDK call.
### Does this PR introduce any user-facing change?
No. Behaviour change is limited to error cases the old loop would have
mishandled (relative-symlink failures and cycles), where callers now get a
wrapped `GlutenException` instead of an incorrect or hung load.
### How was this patch tested?
`mvn -pl gluten-core -Pspark-3.5 spotless:check` passes. New tests
`JniLibLoaderTest` (3 tests) pass against the fix. Each test was also verified
against the old buggy implementation and observed to fail with the expected red
signal (input-verbatim assertion on the regular-file test, path-not-equal on
the chain test, `Assert.fail` on the cycle test). Existing `gluten-core` tests
are unchanged.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
