-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
NPE in error handling leading to 100% CPU #11631
Comments
@konstantin-mikheev We're currently re-investigating this problem, and it seems there are at least a couple of issues at play; I managed to reproduce one of them and I'm working on a fix, but I still need to investigate the other one(s) to better understand what's going on. I'll keep you posted shortly with my progress. |
…) throws an exception Signed-off-by: Ludovic Orban <[email protected]>
@konstantin-mikheev I've created a PR containing a simple change that should mitigate this problem, it's over here: #11637 For some reason I'm still investigating, the HTTP2 headers can become corrupted when a H2 reset frame is sent by the client with the wrong timing, causing the servlet handling code to trap itself in an infinite loop trying to constantly run the same piece of code against the corrupted headers, then handling the exception by adding it as a suppressed to the original one then retying. How the H2 headers corruption happens still need more investigation, even if the stack traces you managed to collect seems to lead to a client sending a H2 reset frame with a bad timing. But a least, with the linked patch, at least Jetty will break the infinite loop. I'd be glad if you could build it, give it a try and report the outcome. Thanks! |
Hey! Sorry for delay. This branch of yours is based also on the jetty version with the spring integration changes there so it is not compatible with the spring version we use But we have cherry picked the commit changes and made a jetty version with those changes exclusively based on 12.0.8 release to be sure nothing else will intervene I have deployed the version with this patch on prod today but we will need some time for the issue to manifest itself. I will update if and when there will be more info |
…uest (#11637) * #11631 abort instead of rethrow when the exception handler in handle() throws an exception * fix ee10 state machine error when client aborts * H3: wire client-sent reset packet on abort * H3: only fail finished streams when fill interested is false --------- Signed-off-by: Ludovic Orban <[email protected]>
We got a bunch of those errors over the last couple of weeks with the @lorban changes applied over 12.0.8 release and those errors have not caused 100% CPU utilisation. It was reproduced for 30+ times on a few different DCs Here is a sample stacktrace from one of those errors:
|
@konstantin-mikheev can you try the staged 12.0.9 release? it contains many more patches than what you are doing. |
Hello, one question regarding this part:
Doesn't this make this issue a denial of service vulnerability which I expect would be of higher priority than a bug and more importantly - more people should be aware of it? |
This issue is considered complete, and was handled by
And the fix is available in Jetty 12.0.9 |
Tested on 12.0.9, there are no loop and here is exception stack trace
|
Will close since the loop does not happen in 12.0.9 and there are no 100% CPU usage |
The loop got sorted out but the original NPE still exists. I've opened #11785 to follow up on that one. Again, if you could come up with a reproducer that would be tremendously helpful. Thanks! |
Jetty version(s)
12.0.7
Jetty Environment
ee10
Java version/vendor
(use: java -version)
OpenJDK Runtime Environment Corretto-21.0.0.35.1 (build 21+35-LTS)
OS type/version
Rocky Linux release 8.8 (Green Obsidian)
Description
Same as #11431 but Spring Boot 3.2.4 and Jetty 12.0.7
It is a reopening of the bug #11431. The commit have not fixed the issue but added logging therefore we have more logs.
There were circular references in logs so I am attaching the full stacktrace of the NPE in error handling as a text file. The later the log, the longer is the stacktrace.
stacktrace.txt
Overall here is the short version of the stacktrace
then there is multiple recurring
then
then a lot of
How to reproduce?
Same as #11431
We do not have the thread dump unfortunately but we have a heap dump this time.
We could not share heapdump for security reasons but if you could point out to specific things I could look it up
The text was updated successfully, but these errors were encountered: