RFR: 8367721: Test compiler/arguments/TestCompileTaskTimeout.java crashed: SIGSEGV

[Marc Chevalier]

On Wed, 17 Sep 2025 06:57:29 GMT, Manuel Hässig <mhaessig at openjdk.org> wrote:

> The test `TestCompileTaskTimeout.java` runs `java -Xcomp -XX:CompileTaskTimeout=1 --version` to demonstrate that the timeout works. Part of the timeout working involves it printing the method of the compile task. Inspecting the core file of the execution that failed with a `SIGSEGV` in the compile task timeout signal handler, the backtrace looks as follows:
> 
> #n   <called signal handler>
> #n+1 CompilerThreadTimeoutLinux::signal_handler()
> #n+2 <called signal handler>
> #n+3 timer_settime()
> #n+4 CompilerThreadTimeoutLinux::disarm()
> #n+5 CompileTaskWrapper::~CompileTaskWrapper()
> 
> So, the compile task hit the timeout during destruction of the underlying `CompileTaskWrapper`. Since the timeout was disarmed only after setting the task to null in the destructor, the signal handler segfaulted when trying to access the method of the compile task to print it out. This PR addresses this issue by moving up the disarmament of the timeout to the top of the destructor.
> 
> Because this issue can only be triggered with bad --- or good, depending on your view --- luck on timing, I could not devise a regression test. But this is not too big of an issue, since the CI already caught this issue.
> 
> Testing:
>  - [ ] Github Actions
>  - [ ] tier1,tier2,tier3 plus stress testing on Oracle supported platforms

That makes a lot of sense to me.

If I understand well, it happens when the compile task is naturally terminating, when compilation is done in pretty much the delay granted by the timeout. It doesn't come from the concurrent handling of the timeout and some other kind of error?

-------------

Marked as reviewed by mchevalier (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27331#pullrequestreview-3233140061