[FLINK-36746][core] Fix the deadlock bug in SerializedThrowable

[RocMarshal]

What is the purpose of the change

• [FLINK-36746][core] Fix the deadlock bug in SerializedThrowable

Brief change log

• [FLINK-36746][core] Fix the deadlock bug in SerializedThrowable

Verifying this change

Add the related test cases in org.apache.flink.runtime.util.SerializedThrowableTest

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): (yes / no)
• The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
• The serializers: (yes / no / don't know)
• The runtime per-record code paths (performance sensitive): (yes / no / don't know)
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (yes / no / don't know)
• The S3 file system connector: (yes / no / don't know)

Documentation

• Does this pull request introduce a new feature? (yes / no)
• If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

[flinkbot]

CI report:

• f947dd1 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[davidradl]

I know this is draught - it would be worth checking if the throwable is already seen before doing any logic to consider adding it.

[RocMarshal]

Hi, @Myasuka Could u help take a look if you had the free time ?
Thanks

[Myasuka]

Please improve the test code to avoid possible endless running.

[Myasuka]

I don't this test is stable without timeout limit, if we do not fix the original code in flink-core/src/main/java/org/apache/flink/util/SerializedThrowable.java, this test would run endlessly without quit properly.

[RocMarshal]

---

---

Hi, @Myasuka Thanks for your reminding.

I increased the number of test runs for the current test case using RepeatedTest and found that deadlocks can indeed still occur.

We considered a solution: making all methods of SerializedThrowable private, thereby controlling the creation of SerializedThrowable objects through a single unified entry point. The goal was to try to elevate the locking hierarchy to the serialized exception object itself.

Unfortunately, the following situation can still occur:

When one thread calls the unified creation method, another thread may already be holding the object lock of another exception object referenced within the exception. In such a case, a deadlock can still potentially happen.

Looking forward to your thoughts on this~
Any input is aprreciated !