linux-arm64: protobuf duplicate registration issue

[snadampal]

Please make sure that this is a build/installation issue. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:build_template

System information

• OS Platform and Distribution (e.g., Linux Ubuntu 16.04 x86_64): Ubuntu 22.04 on arm64
• TensorFlow installed from (source or binary): Binary
• TensorFlow version: 2.16.1
• Java version (i.e., the output of java -version): openjdk 11.0.23 2024-04-16
• Java command line flags (e.g., GC parameters):
• Installed from Maven Central?: No
• Bazel version (if compiling from source):
• GCC/Compiler version (if compiling from source):
• CUDA/cuDNN version:
• GPU model and memory:

Describe the problem
I've added support for linux-arm64 platform java builds, here is the PR. With this I'm able to build the jars, but tests are failing with protobuf file already exists in the database error.

From some reading, it looks like it will happen if we are loading multiple copies on protobuf .so. From the logs I didn't see any such obvious thing.

Provide the exact sequence of commands / steps that you executed before running into the problem

git clone https://github.com/tensorflow/java.git
// apply PR: https://github.com/tensorflow/java/pull/545
mvn install -X -T 16

Any other info / logs
Include any logs or source code that would be helpful to diagnose the problem. If including tracebacks, please include the full traceback. Large logs and files should be attached.

backtrace:

[INFO] Running org.tensorflow.internal.c_api.GradientTest
2024-06-14 22:29:05.332756: I tensorflow/core/util/port.cc:113] oneDNN custom operations are on. You may see slightly different numerical results due to floating-point round-off errors from different computation orders. To turn them off, set the environment variable `TF_ENABLE_ONEDNN_OPTS=0`.
[libprotobuf ERROR external/com_google_protobuf/src/google/protobuf/descriptor_database.cc:642] File already exists in database: tensorflow/core/data/service/common.proto
[libprotobuf FATAL external/com_google_protobuf/src/google/protobuf/descriptor.cc:1986] CHECK failed: GeneratedDatabase()->Add(encoded_file_descriptor, size): 
terminate called after throwing an instance of 'google::protobuf::FatalException'
  what():  CHECK failed: GeneratedDatabase()->Add(encoded_file_descriptor, size): 
Aborted (core dumped)
[DEBUG] Closing the fork 1 after not saying Good Bye.

[snadampal]

Looks like the issue is due to loading the shared libraries multiple times from different classes. for example, I see Loader.load()call is present in both the following files and is causing the above error on linux-arm64 platform. If I comment the loading from the GradFunctAdapter.java, the GradientTest is passing on linux-arm64 platform as well.

https://github.com/tensorflow/java/blob/v1.0.0-rc.1/tensorflow-core/tensorflow-core-native/src/gen/java/org/tensorflow/internal/c_api/global/tensorflow.java#L12
and
https://github.com/tensorflow/java/blob/v1.0.0-rc.1/tensorflow-core/tensorflow-core-native/src/gen/java/org/tensorflow/internal/c_api/TFJ_GradFuncAdapter.java#L21

I'm wondering why it's not a problem for linux-x86 platform? does anyone have a clue?

[saudet]

Both calls to Loader.load() will load the same library. The problem is most likely somewhere else. Please set the "org.bytedeco.javacpp.logger.debug" system property to "true" to get more information on the console.

[snadampal]

@saudet thanks for letting me know the javacpp debug property, the debug logs are very helpful. I'm able to root-cause and fix the issue, it was because the first time loading was not successful, so, the second time loading was happening and failing with duplicate files. I will submit a PR for the fix.

[snadampal]

I have raised #545 to fix the native crashes. closing this issue.