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

[Manuel Hässig]

On Wed, 17 Sep 2025 07:49:47 GMT, Marc Chevalier <mchevalier 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?

Thank you for taking a look, @marc-chevalier.

> It doesn't come from the concurrent handling of the timeout and some other kind of error?

There is only one timeout going on for every compile task and thus for every compiler thread and they are delivered directly to the native thread running the compiler thread with the timed out compile task. Since `CompileTask`s are thread local, this cannot come from concurrent timeouts. I can successfully exclude other kinds of errors, because the timeout signal handler does not have any other ways to segfault other than on accessing the task, because it does not use any of the pointers passed to it.

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

PR Comment: https://git.openjdk.org/jdk/pull/27331#issuecomment-3302151009