-
Notifications
You must be signed in to change notification settings - Fork 738
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
prunsrv.exe (Tomcat10.exe) killed when run on top of openj9 #19892
Comments
Is it feasible to run using |
@pshipton, I just tried with |
@hzongaro fyi |
@a7ehuo, may I ask you to look at this problem? |
@qooalt Could you take a look at the steps and the logs to confirm what I observed is the same as what you saw? Thank you very much in advance!
I don't see much in the logs yet under Found the following in the Event Viewer:
|
So far I narrowed it down to one compiled method Bad
Good
And it's possibly related to
@qooalt May I ask you to run with the following java option to exclude the method and see if the problem goes away for you? If the problem goes away, at least it confirms we are looking at the right method. Thank you very much!
|
@a7ehuo, confirmed that with this java option it works. |
Yes, that's exactly it. |
I compared the passed case [1] and the failed case [2]. The difference between them in IL trees is
I attached the debugger to the running
Stepping by instruction, the next instruction hits exception
This What is introduced in apache/commons-daemon@fed3689 is that it enables Control Flow Guard (CFG): I also tried adding [1]
[2]
[3]
[4]
[5]
[6]
|
@a7ehuo, not sure to get that. Are you saying that this case should be allowed, and the problem is in Apache Commons and/or in how Windows (or the compiler) handles the situation when CFG is enabled? |
I'm still looking. I'll update when I have some answer |
Just an update on what I found on how implicit NULLCHK fails CFG:
If CFG is enabled, When the test instruction (
TEB.StackLimit is
In The Java stack pointer SP (
|
@a7ehuo, is there anything the JIT (or the JVM) can do about this? Moving this out to 0.49 for now. . . . |
Unfortunately, I have not found anything that the JIT (or the JVM) can do about this case when CFG is enabled |
Hi! I've also seen this using tomcat 9.0.94. So it's not only on tomcat 10. For now I just disabled CFG from Exploit programs in Windows Settings. |
Hi @a7ehuo , I see this PR getting referenced from cases so I just wanted to check on a couple of things. |
Oh, looks like it's not implicit nullchecks but a modified explicit nullcheck? I read more and found your reference to #5708 and the suggestion to use |
This is also what my understanding is, but I don't know why it limits to a number of JIT'd methods
Here are a fews of workarounds
|
We have potential workarounds for the problem, but no viable fix yet. Moving this to the Backlog until we are able to come up with a way of avoiding the problem completely. |
Was there any success in getting diagnostic data from this scenario, or was all the debugging done live? |
I debugged the issue live |
If CFG is enabled, set TR_NoResumableTrapHandler in the JIT. Fixes: eclipse-openj9#19892 Signed-off-by: Annabelle Huo <[email protected]>
If Control Flow Guard (CFG) is enabled in Windows, set TR_NoResumableTrapHandler in the JIT. This change relies on API GetProcessMitigationPolicy. Its minimum supported client version is Windows 8 and its minimum supported server version is Windows Server 2012. Fixes: eclipse-openj9#19892 Signed-off-by: Annabelle Huo <[email protected]>
If Control Flow Guard (CFG) is enabled in Windows, set TR_NoResumableTrapHandler in the JIT. This change relies on API GetProcessMitigationPolicy. Its minimum supported client version is Windows 8 and its minimum supported server version is Windows Server 2012. Fixes: eclipse-openj9#19892 Signed-off-by: Annabelle Huo <[email protected]>
If Control Flow Guard (CFG) is enabled in Windows, set TR_NoResumableTrapHandler in the JIT. This change relies on API GetProcessMitigationPolicy. Its minimum supported client version is Windows 8 and its minimum supported server version is Windows Server 2012. Fixes: eclipse-openj9#19892 Signed-off-by: Annabelle Huo <[email protected]>
This change relies on API GetProcessMitigationPolicy. Its minimum supported client version is Windows 8 and its minimum supported server version is Windows Server 2012. Fixes: eclipse-openj9#19892 Signed-off-by: Annabelle Huo <[email protected]>
This change relies on API GetProcessMitigationPolicy. Its minimum supported client version is Windows 8 and its minimum supported server version is Windows Server 2012. Fixes: eclipse-openj9#19892 Signed-off-by: Annabelle Huo <[email protected]>
This change relies on API GetProcessMitigationPolicy. Its minimum supported client version is Windows 8 and its minimum supported server version is Windows Server 2012. Fixes: eclipse-openj9#19892 Signed-off-by: Annabelle Huo <[email protected]>
This change relies on API GetProcessMitigationPolicy. Its minimum supported client version is Windows 8 and its minimum supported server version is Windows Server 2012. Fixes: eclipse-openj9#19892 Signed-off-by: Annabelle Huo <[email protected]>
This change relies on API GetProcessMitigationPolicy. Its minimum supported client version is Windows 8 and its minimum supported server version is Windows Server 2012. Fixes: eclipse-openj9#19892 Signed-off-by: Annabelle Huo <[email protected]>
Tomcat service in Windows with openJ9 crashes when certain Java code is executed. This seems to happen because starting with 1.4.0, Commons Daemon enables the Control Flow Guard flag, and some specific java code executed by the openj9 runtime triggers it, killing the process. The problem does occur when the code attached is executed, but not only with it. This is just the simplest way I found to recreate the problem.
The same code works with Tomcat 10.1.24 (which uses Commons Daemon 1.3.4, if I'm not wrong), but crashes both with 10.1.25 and 10.1.26 (both using Commons Daemon 1.4.0).
This same code does work fine using Temurin runtime, with the same Java version as the used with Semeru openJ9 (17.0.11_9 x64)
Steps to reproduce:
No significant messages are written in the log files, and the error shown in the event viewer shows the following information:
Faulting application name: Tomcat10125.exe, version: 1.4.0.0, time stamp: 0x664770c7
Faulting module name: ntdll.dll, version: 10.0.22621.3733, time stamp: 0x67ca8829
Exception code: 0xc0000409
Fault offset: 0x000000000006d915
Faulting process id: 0x0xCF60
Faulting application start time: 0x0x1DAD29C07116CFB
Faulting application path: C:\Program Files\Apache Software Foundation\Tomcat 10.1_Tomcat10125\bin\Tomcat10125.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: 59f71851-e580-428b-84ce-d1ac220970f4
Faulting package full name:
Faulting package-relative application ID:
As said, based on my research, the issue seems to be related to this commit in Commons Daemon.
apache/commons-daemon@fed3689
The tests I performed:
I built prunsrv.exe in debug mode, replaced Tomcat10.exe by it, and it does not crash.
I built prunsrv.exe in release mode, replaced Tomcat10.exe by it, and it does crash.
I built prunsrv.exe in release mode commenting out the Control Flow Guard flag introduced in that commit, and it does not crash.
I installed replaced Semeru by Temurin, same Java version, and it does not crash.
For your reference, I first reported the bug in Tomcat's bugzilla: https://bz.apache.org/bugzilla/show_bug.cgi?id=69180
And then in Commons Daemon, where they claim this is an openj9 issue, not a Commons Daemon one:
https://issues.apache.org/jira/browse/DAEMON-465
helloworldsvg.zip
The text was updated successfully, but these errors were encountered: