[ANN] Apache Tomcat 8.5.96 available

[Christopher Schultz]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.96.

Apache Tomcat 8 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 8.5.96 is a bugfix and feature release. The notable
changes compared to 8.5.95 include:

- Fix reloading TLS configuration could cause the Connector to
  refuse new connections or the JVM to crash.

- Ensure that an IOException during the reading of the request
  always triggers error handling, regardless of whether the
  application swallows the exception.

- The status manager servlet can now output statistics as json.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-8.5-doc/changelog.html

Downloads:
https://tomcat.apache.org/download-80.cgi

Migration guides from Apache Tomcat 7.x and 8.0:
https://tomcat.apache.org/migration.html

Please note that Tomcat 8.5.x will reach End-of-life (EOL) on 31 March 
2024. For more information please visit 
https://tomcat.apache.org/tomcat-85-eol.html


Enjoy!

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] Is the HTTP/2 Rapid Reset Exploit still possible on 2.4.58?

[Christopher Schultz]

All,

On 11/13/23 17:36, Chuck Caldarale wrote:

You may have the wrong mailing list - this one is for Tomcat, but your query 
seems to be solely about Apache httpd.


Also, the httpd project has stated that they were never vulnerable to 
CVE-2023-44487.


https://github.com/icing/blog/blob/main/h2-rapid-reset.md

To be fair, this is not an "official" statement by the httpd team.

With httpd 5.4.58, you should be covered for not only CVE-2023-44487 (h2 
rapid reset, which was never really a problem) but also CVE-2023-45802 
which was exposed by testing httpd for CVE-2023-44487, but is in fact a 
separate issue, now fixed in 5.4.88.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: AW: FileUpload class not working with Tomcat 10.1

[Thomas Hoffmann (Speed4Trade GmbH)]

Hi Mark!

> -Ursprüngliche Nachricht-
> Von: Mark Foley 
> Gesendet: Dienstag, 14. November 2023 18:20
> An: users@tomcat.apache.org
> Betreff: Re: AW: FileUpload class not working with Tomcat 10.1
> 
> On Tue Nov 14 01:46:09 2023 "Thomas Hoffmann (Speed4Trade GmbH)"
>  wrote:
> >
> > Hello Mark,
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Mark Foley 
> > > Gesendet: Montag, 13. November 2023 23:12
> > > An: users@tomcat.apache.org
> > > Betreff: Re: AW: FileUpload class not working with Tomcat 10.1
> > >
> > > On Mon Nov 13 02:18:49 2023 "Thomas Hoffmann (Speed4Trade GmbH)"
> > >  wrote:
> > > > Hello,
> > > >
> > > > > -Ursprüngliche Nachricht-
> > > > > Von: Mark Foley 
> > > > > Gesendet: Sonntag, 12. November 2023 19:04
> > > > > An: users@tomcat.apache.org
> > > > > Betreff: Re: FileUpload class not working with Tomcat 10.1
> > > > >
> > > > > On Fri Nov 10 15:57:50 2023 Christopher Schultz
> > > > >  wrote:
> > > > > >
> > > > > > Mark,
> > > > > >
> > > > > > On 11/10/23 12:53, Mark Foley wrote:
> > > > > > > On Fri, 10 Nov 2023 17:11:59 Mark Thomas  > > wrote:
> > > > > > >>
> > > > > > >> On 10/11/2023 16:49, Mark Foley wrote:
> > > > > > >>> I recently upgraded from Tomcat 10.0.17 to 10.1.13.  ...
> > > > > > >>>
> > > > > > >>> [deleted]
> > > > > >
> > > > > I've put your suggested code in place.
> > > > >
> > > > > <%@ page import="jakarta.servlet.http.Part" %>
> > > > >
> > > > > I replaced your:
> > > > >
> > > > >   throw new IllegalStateException("Expected multi-part");
> > > > >
> > > > > with:
> > > > >
> > > > > out.println("Expected multi-part");
> > > > >
> > > > > Just to get things compiling OK.  I'll deal with errors later.
> > > > > With that change, it compiled w/o problem.  I then attempted an
> > > > > upload.  The
> > > line:
> > > > >
> > > > >if(null == contentType ||
> > > > > !contentType.startsWith("multipart/form-data;"))
> > > > > {
> > > > >
> > > > > returned TRUE so it did detect a multipart upload. Yay! That was
> > > > > a relief However
> > > > >
> > > > >Part fileUpload = request.getPart("param-name");
> > > > >
> > > > > Gave me the error:
> > > > >
> > > > > java.lang.IllegalStateException: Unable to process parts as no
> > > > > multi-part configuration has been provided
> > > > >
> > > > > So, what does it mean that "no multi-part configuration has been
> > > provided"?
> > > > > Is "param-name" something I'm supposed to fill in? I tried
> > > > > substituting the  field name, "taxResults",
> > > > > but that
> > > gave the same error.
> > > >
> > > > The form element must have the attribute enctype="multipart/form-
> > > data".
> > > > Furthermore, the servlet must be annotated by "@MultipartConfig"
> > > >
> > > > I think for jsp files, there is a similar setting in the web.xml.
> > > > This link might help out:
> > > > https://stackoverflow.com/questions/37965890/add-annotation-to-jsp
> > >
> > > Thanks for your reply Thomas.
> > >
> > > I've checked your suggested link and I have no idea where to put all
> > > that  stuff.  Furthermore, the poster of that issue didn't say
> > > he got it working.
> > >
> > > A respnder to the post said, "Actually every jsp file will be
> > > converted to servlet because tomcat can only address servlet and so
> > > every jsp file is indirectly a servlet and has all the features of
> > > it". I think he is suggesting that the  code is superfluous, but not
> exlpicitly stated as such.
> > >
> > > I am getting a TRUE return for
> > >
> > >   if(null == contentType ||
> > > !contentType.startsWith("multipart/form-data;"))
> > >
> > > so I think it is recognizing it as "multipart/form-data;".
> > >
> > > Does anyone have an example of a JSP program with
> > > jakarta.servlet.http.Part class?
> > >
> > > I'll search for examples as well, but I really have no idea how to 
> > > proceed.
> > >
> > > --Mark F.
> > >
> >
> > The servlet specification defines the special folder WEB-INF.
> > Within this folder, there is the configuration file named web.xml.
> > Within this xml-File, the application is configured including the servlets.
> > JSP-Files are compiled to servlets, either on-the-fly or during compilation
> time.
> >
> > I would recommend to take a look at some sample applications to get
> familiar with some java web-applications and the web.xml file.
> >
> > It is not only about the jsp-file but also the combination with the
> > application configuration within the web.xml Thus you will need both, jsp-
> file and a corresponding web.xml configuration.
> >
> > Greetings!
> > Thomas
> 
> Thomas, I would LOVE to find some examples on this application! I've spent
> days searching and mostly I've found examples for pre 10.1 Tomcat, including
> numerous examples of the type Christopher Schultz found "horrifying".
> Christopher Schultz's suggested example imported
> "jakarta.servlet.http.Part", but your link example doesn't mention that class
> and instead imports 

Re: CredentialHandler not working for MD5

[Mark Thomas]

You are confusing DIGEST authentication and digested passwords. The two 
are separate but related processes. If you use both, you do need to 
ensure that they are using the same digest.


There is no need to modify code. This call all be controlled via 
configuration.


https://tomcat.apache.org/tomcat-9.0-doc/realm-howto.html#Digested_Passwords

Look for "If using digested passwords with DIGEST authentication"

I suggest you do this in stages.

1. Configure BASIC auth with clear-text passwords in the Realm and get 
that working.
2. Switch to DIGEST auth with clear-text passwords in the Realm and get 
that working.

3. Then configure DIGEST auth and digested passwords in the Realm.

Mark



On 14/11/2023 00:04, Peter Otto wrote:

More info….



In the Request Header-> Authorization->Response.  Response is used as the 
clientDigest.  However this response is generated, it is incorrect.

Need to understand where Tomcat generates this Response because it is used for 
comparison of the serverDigest.  And if the server digest equals the 
clientDigest, then it works.



The way I understand it, the clientDigest comes from the client entering in the 
username/pwd on the popup box.




From: Peter Otto 
Date: Monday, November 13, 2023 at 11:05 AM
To: Tomcat Users List 
Subject: Re: CredentialHandler not working for MD5
Chris,

Running the debugger, I found out the DigestAuthenticator wants to use SHA-256. 
  8 months ago there was a change for RFC 7616.
https://urldefense.com/v3/__https://github.com/apache/tomcat/blob/9.0.74/java/org/apache/catalina/authenticator/DigestAuthenticator.java__;!!P192cPdC!gngwaC1JS3mDrQRjm-kpcOFNPuIBaF56P2aVV9vgLqK1CJAqprPgZBsUjm671wxFYUYKD6tJCCzjvQLczAw0$

To bypass the array of digest,
I commented out some code so it was forced to use MD5 only.

But In the RealmBase, I really don’t understand what getDigest is doing.
When I create a MD5 digest, I use Username:Realm:Password.
In the code it is using Nonce, nc, cnonce, gop…..




From: Christopher Schultz 
Date: Friday, November 10, 2023 at 1:44 PM
To: users@tomcat.apache.org 
Subject: Re: CredentialHandler not working for MD5
Peter,

On 11/10/23 16:30, Peter Otto wrote:

With 9.0.82, and the latest version 10, I get the same problem.
So I assume it stopped working since 9.0.74 all the way up to 9.0.82

Removing the Realm LockOutRealm did not work either.


Thanks for double-checking both of those.

I don't see anything in the changelog that seems like it would be
related. Thing I suspect are related were in an earlier release.

Are you able to run under a debugger, and are you comfortable doing
that? It's pretty easy to set a breakpoint in the Realm and/or
CredentialHandler to see what's being done when you try to authenticate.

-chris


From: Christopher Schultz 
Date: Friday, November 10, 2023 at 12:35 PM
To: users@tomcat.apache.org 
Subject: Re: CredentialHandler not working for MD5
Peter,

On 11/10/23 13:27, Peter Otto wrote:

Logging into manager using MD5 works in 9.0.73 but now fails in 9.0.74->current
Steps to reproduce.

Step 1. Run C:\tomcat\bin> .\digest.bat -a md5 -s 0 -i 1 
tomcat:UserDatabase:nobueno

tomcat:UserDatabase:nobueno:bb6c1c32b9b6df4f707c0e58f2c900e0


Step 2. Use the digest # and place it in tomcat-users.xml





Step 3. Edit server.xml and add the CredentialHandler to use MD5









Step 4. Edit the web.xml in manager to say

   DIGEST
   UserDatabase
 

Step 5 start tomcat and try to access the manager.
On WIndows 2019 server/Chrome/OpenJDK11  type tomcat for the user
and nobueno for the password.

This would work on versions 9.0.73 and earlier

This stopped working from 9.0.74 and onwards.
The way to access the manager from 9.0.74+ is to use 
bb6c1c32b9b6df4f707c0e58f2c900e0 as the password.
In other words the text in tomcat-user.xml is the password.

Anyone have any ideas how to fix this?  I have to use 9.0.74+ version of tomcat 
because of CVEs.


If you temporarily remove the LockOutRealm, does the correct password work?

If you upgrade to 9.0.82, does the correct password work?

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
This e-mail and any files transmitted with it are the property of Arthrex, Inc. 
and/or its affiliates, are confidential, and are intended solely for the use of 
the individual or entity to whom this e-mail is addressed. If you are not one 
of the named recipient(s) or otherwise have reason to believe that you have 
received this message in error, please notify the sender at 239-643-5553 and 
delete this message immediately from your computer. Any other use, retention, 
dissemination 

Re: Accessing Credential handler inside the web application always returns null

[Mark Thomas]

On 12/11/2023 23:01, Усманов Азат Анварович wrote:

Sorry for delayed response, Once I comment out the CredentialHandler in context 
xml both in my app's context.xml and in global context.xml, and add realm to 
server.xml. CredentialHandler returns null once again.


This is by design.

The context attribute is only populated if the Realm is defined on the 
context.


I think you'll need to use reflect to get at the information you want.

Mark



От: Christopher Schultz 
Отправлено: 5 ноября 2023 г. 18:16
Кому: users@tomcat.apache.org 
Тема: Re: Accessing Credential handler inside the web application always 
returns null

Азат,

On 10/31/23 13:53, Усманов Азат Анварович wrote:

Hi everyone! CredentialHandler became not null, as soon as I
transferred Realm definition from server.xml to context.xml(after
checking the source code) .I've been able to see the new pbkdf2
version of the given clear text password even with old  9.0.64
version. I was wondering is the necessity to have realm defined
inside context. xml for accessing CredentialHandler a design decision
or a possible  bug in tomcat itself?. It wasn't mentioned in tomcat
documentation. Perhaps it should be added in the docs.

Hmm... it shouldn't matter if you define your  in server.xml or
in app/META-INF/context.xml. Are you sure that was the only difference
between working/not-working configurations?

Thanks,
-chris



От: Усманов Азат Анварович 
Отправлено: 30 октября 2023 г. 20:25
Кому: users@tomcat.apache.org 
Тема: RE: Accessing Credential handler inside the web application always 
returns null

I did recheck using 9.0.82, unfortunately nothing has changed CredentialHandler 
is still null

От: Christopher Schultz 
Отправлено: 30 октября 2023 г. 18:52
Кому: Tomcat Users List ; Усманов Азат Анварович 

Тема: Re: Accessing Credential handler inside the web application always 
returns null

Азат,

On 10/29/23 20:45, Усманов Азат Анварович wrote:

Hi everyone!I'm trying to test CredentialHandeler functionality onour test 
server (Tomcat 9.0.64) inside the web-app
I Our realm is defined as follows( excerpt from server.xml
)
   
  



  
Currently pwd  column defined as  Oracle (RAW) only stores md5 hashes, I was 
hoping to upgrade to PBKDF2 using tomcat ?so  here is the relevant part basic  
login  controller code  (LoginCheckServlet)
LoginCheckServlet

  protected void doGet(HttpServletRequest request, HttpServletResponse 
response) throws ServletException, IOException {
...
  String userName = request.getParameter("j_username");
String password = request.getParameter("j_password");
  HttpSession session = request.getSession();

 UserRecord user=... //load data from db
if 
(user.checkCorrectPassword(password,session.getServletContext())) {
  CredentialHandler 
cr=Security.getCredentialHandler(getServletContext());
  System.out.println(cr.mutate(password));// hoping 
to see my password displayed as pbkdf2 hash

.
}

Security.getCredentialHandler

  public static CredentialHandler getCredentialHandler(final ServletContext 
context) {
System.out.println("context"+context) ;// prints 
contextorg.apache.catalina.core.ApplicationContextFacade@33f1f7c7
System.out.println("context vs"+context.getMajorVersion()); // 
prints 4

System.out.println("ATRIB"+context.getAttribute(Globals.CREDENTIAL_HANDLER));//always
  prints ATRIB null
return (CredentialHandler) 
context.getAttribute(Globals.CREDENTIAL_HANDLER);
}


Your code and configuration looks reasonable to me.


So basically it always  return null  when trying to access
CredentialHandler attribute inside Security.getCredentialHandler
method,Any idea why it might be the case ?

Are you able to re-try with Tomcat 9.0.70 or later? There is a
changelog[1] entry which may be important for you:

"
Fix: Improve the behavior of the credential handler attribute that is
set in the Servlet context so that it actually reflects what is used
during authentication. (remm)
"

There was a problem specifically with the NestedCredentialHandler, I
think, which was not working as expected. 9.0.70 includes a fix that
should improve things for you.

-chris


[1]
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html#Tomcat_9.0.70_(remm)


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: AW: FileUpload class not working with Tomcat 10.1

[Mark Foley]

On Tue Nov 14 01:46:09 2023 "Thomas Hoffmann (Speed4Trade GmbH)" 
 wrote:
>
> Hello Mark,
>
> > -Ursprüngliche Nachricht-
> > Von: Mark Foley 
> > Gesendet: Montag, 13. November 2023 23:12
> > An: users@tomcat.apache.org
> > Betreff: Re: AW: FileUpload class not working with Tomcat 10.1
> > 
> > On Mon Nov 13 02:18:49 2023 "Thomas Hoffmann (Speed4Trade GmbH)"
> >  wrote:
> > > Hello,
> > >
> > > > -Ursprüngliche Nachricht-
> > > > Von: Mark Foley 
> > > > Gesendet: Sonntag, 12. November 2023 19:04
> > > > An: users@tomcat.apache.org
> > > > Betreff: Re: FileUpload class not working with Tomcat 10.1
> > > >
> > > > On Fri Nov 10 15:57:50 2023 Christopher Schultz
> > > >  wrote:
> > > > >
> > > > > Mark,
> > > > >
> > > > > On 11/10/23 12:53, Mark Foley wrote:
> > > > > > On Fri, 10 Nov 2023 17:11:59 Mark Thomas  > wrote:
> > > > > >>
> > > > > >> On 10/11/2023 16:49, Mark Foley wrote:
> > > > > >>> I recently upgraded from Tomcat 10.0.17 to 10.1.13.  ...
> > > > > >>>
> > > > > >>> [deleted]
> > > > >
> > > > I've put your suggested code in place.
> > > >
> > > > <%@ page import="jakarta.servlet.http.Part" %>
> > > >
> > > > I replaced your:
> > > >
> > > >   throw new IllegalStateException("Expected multi-part");
> > > >
> > > > with:
> > > >
> > > > out.println("Expected multi-part");
> > > >
> > > > Just to get things compiling OK.  I'll deal with errors later. With
> > > > that change, it compiled w/o problem.  I then attempted an upload.  The
> > line:
> > > >
> > > >if(null == contentType ||
> > > > !contentType.startsWith("multipart/form-data;"))
> > > > {
> > > >
> > > > returned TRUE so it did detect a multipart upload. Yay! That was a
> > > > relief However
> > > >
> > > >Part fileUpload = request.getPart("param-name");
> > > >
> > > > Gave me the error:
> > > >
> > > > java.lang.IllegalStateException: Unable to process parts as no
> > > > multi-part configuration has been provided
> > > >
> > > > So, what does it mean that "no multi-part configuration has been
> > provided"?
> > > > Is "param-name" something I'm supposed to fill in? I tried
> > > > substituting the  field name, "taxResults", but that
> > gave the same error.
> > >
> > > The form element must have the attribute enctype="multipart/form-
> > data".
> > > Furthermore, the servlet must be annotated by "@MultipartConfig"
> > >
> > > I think for jsp files, there is a similar setting in the web.xml.
> > > This link might help out:
> > > https://stackoverflow.com/questions/37965890/add-annotation-to-jsp
> > 
> > Thanks for your reply Thomas.
> > 
> > I've checked your suggested link and I have no idea where to put all that
> >  stuff.  Furthermore, the poster of that issue didn't say he got it
> > working.
> > 
> > A respnder to the post said, "Actually every jsp file will be converted to
> > servlet because tomcat can only address servlet and so every jsp file is
> > indirectly a servlet and has all the features of it". I think he is 
> > suggesting that
> > the  code is superfluous, but not exlpicitly stated as such.
> > 
> > I am getting a TRUE return for
> > 
> >   if(null == contentType || !contentType.startsWith("multipart/form-data;"))
> > 
> > so I think it is recognizing it as "multipart/form-data;".
> > 
> > Does anyone have an example of a JSP program with
> > jakarta.servlet.http.Part class?
> > 
> > I'll search for examples as well, but I really have no idea how to proceed.
> > 
> > --Mark F.
> > 
>
> The servlet specification defines the special folder WEB-INF.
> Within this folder, there is the configuration file named web.xml.
> Within this xml-File, the application is configured including the servlets.
> JSP-Files are compiled to servlets, either on-the-fly or during compilation 
> time.
>
> I would recommend to take a look at some sample applications to get familiar 
> with some java web-applications and the web.xml file.
>
> It is not only about the jsp-file but also the combination with the 
> application configuration within the web.xml
> Thus you will need both, jsp-file and a corresponding web.xml configuration.
>
> Greetings!
> Thomas

Thomas, I would LOVE to find some examples on this application! I've spent days
searching and mostly I've found examples for pre 10.1 Tomcat, including numerous
examples of the type Christopher Schultz found "horrifying". Christopher
Schultz's suggested example imported "jakarta.servlet.http.Part", but your link
example doesn't mention that class and instead imports
"javax.servlet.annotation.MultipartConfig". 

As I said, an actual working example somewhere would be nice.

I've used WEB-INF/web.xml for several context definitions, so I am familiar with
it, but have never configured a servlet in web.xml.

Anyway, enough griping! I have gotten it partially working thanks to your
suggested link, and particulary you suggestion to put the servlet info in
web.xml.  I've put the following in WEB-INF/web.xml:

   
  uploadfile
/schDistImportResultsX.jsp
  

Re: Tomcat 10.1.15 JVM crashes randomly on startup

[Suvendu Sekhar Mondal]

Hello Øyvind,

> While I'm waiting for my hosting provider to disable the Sentinel Agent, I'm 
> attaching a full crash report below, from another crash this morning.

That's a good idea. After removal if JVM is not crashing abruptly,
you'll be certain that Sentinel agent is the problem.

You can also try to extract thread details out of the crash dump and
look at the "https-openssl-nio-0.0.0.0-443-exec-27" thread. jstack can
help. Command will be something like: jstack -J-d64 JAVA_HOME\bin\java
E:\tomcat10\hs_err_pid15260.mdmp
Please use the same JRE which produced the dump to avoid any
incompatibility issue.

On Tue, Nov 14, 2023 at 3:28 PM Øyvind Flatval
 wrote:
>
> > From: Mark Thomas 
> > Sent: Monday, November 13, 2023 09:15
> > To: users@tomcat.apache.org 
> > Subject: Re: Tomcat 10.1.15 JVM crashes randomly on startup
> >
> > On 13/11/2023 07:52, Øyvind Flatval wrote:
> > > Greetings!
> > >
> > > We are currently experiencing a very vague problem with our Tomcat 10.1 
> > > instance, where the JVM will crash almost instantly after Tomcat is done 
> > > starting up.
> > > The problem happens somewhat regularly, and only happens within the first 
> > > minute after starting Tomcat. The solution is always to just attempt to 
> > > restart Tomcat and this usually only take 1 attempt.
> > >
> > >
> > > Tomcat is running a single web application, that sees traffic over both 
> > > Websocket (several 100 clients) and Https (maybe 20-40 users during peak 
> > > + a few API clients)
> > >
> > > Our setup is a somewhat old VM.
> > > Windows Server 2016 Standard 1607, buil 14343.6351
> > > Intel Xeon E5-2680 v4 @ 2.40 GHz
> > > 4 x Cores
> > > 8 GB Memory
> > >
> > > JRE version: OpenJDK Runtime Environment Temurin-17.0.8.1+1 (17.0.8.1+1) 
> > > (build 17.0.8.1+1)
> > > Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.8.1+1 (17.0.8.1+1, mixed 
> > > mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, 
> > > windows-amd64)
> > >
> > > Tomcat version is 10.1.15 64 bit
> > >
> > > The company we rent our VM servers from has installed Sentinel One that 
> > > connects to the JVM through an agent. I have very little knowledge of 
> > > what if anything this can do. Since this is the only thing out of the 
> > > ordinary running on this setup, my fear is that this might be causing the 
> > > crashes.
> >
> > Some web searching suggests that is certainly likely.
> >
> > > I include a partial example of the exception log here, some data may have 
> > > been removed for privacy reasons. Please let med know if I should include 
> > > the full file, since I've removed parts of it due to pure length.
> >
> > The full file might contain a few more hints as to what went wrong.
> >
> > Mark
> >
>
> While I'm waiting for my hosting provider to disable the Sentinel Agent, I'm 
> attaching a full crash report below, from another crash this morning.
>
> >
> > >
> > > #
> > > # A fatal error has been detected by the Java Runtime Environment:
> > > #
> > > #  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x1131b169, 
> > > pid=2084, tid=5160
> > > #
> > > # JRE version: OpenJDK Runtime Environment Temurin-17.0.8.1+1 
> > > (17.0.8.1+1) (build 17.0.8.1+1)
> > > # Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.8.1+1 (17.0.8.1+1, mixed 
> > > mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, 
> > > windows-amd64)
> > > # Problematic frame:
> > > # j  
> > > jakarta.servlet.http.HttpServletRequestWrapper.getDateHeader(Ljava/lang/String;)J+1
> > > #
> > > # Core dump will be written. Default location: 
> > > E:\tomcat10\hs_err_pid2084.mdmp
> > > #
> > > # If you would like to submit a bug report, please visit:
> > > #   https://github.com/adoptium/adoptium-support/issues
> > > #
> > >
> > > ---  S U M M A R Y 
> > >
> > > Command Line: -Dcatalina.home=E:\tomcat10 -Dcatalina.base=E:\tomcat10 
> > > -Dignore.endorsed.dirs=E:\tomcat10\endorsed 
> > > -Djava.io.tmpdir=E:\tomcat10\temp 
> > > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
> > > -Djava.util.logging.config.file=E:\tomcat10\conf\logging.properties 
> > > -Djava.locale.providers=COMPAT 
> > > --add-opens=java.base/java.lang=ALL-UNNAMED 
> > > --add-opens=java.base/java.io=ALL-UNNAMED 
> > > --add-opens=java.base/java.util=ALL-UNNAMED 
> > > --add-opens=java.base/java.util.concurrent=ALL-UNNAMED 
> > > --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED exit abort -Xms768m 
> > > -Xmx5090m -agentpath:C:\Program Files\SentinelOne\Sentinel Agent 
> > > 22.3.4.612\SentinelJava64.dll
> > >
> > > Host: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz, 4 cores, 7G,  Windows 
> > > Server 2016 , 64 bit Build 14393 (10.0.14393.5786)
> > > Time: Sat Nov 11 18:18:30 2023 W. Europe Standard Time elapsed time: 
> > > 153.828934 seconds (0d 0h 2m 33s)
> > >
> > > ---  T H R E A D  ---
> > >
> > > Current thread (0x2e6a9bd0):  JavaThread 
> > > 

Re: Tomcat 10.1.15 JVM crashes randomly on startup

[Øyvind Flatval]

> From: Mark Thomas 
> Sent: Monday, November 13, 2023 09:15
> To: users@tomcat.apache.org 
> Subject: Re: Tomcat 10.1.15 JVM crashes randomly on startup
>  
> On 13/11/2023 07:52, Øyvind Flatval wrote:
> > Greetings!
> >
> > We are currently experiencing a very vague problem with our Tomcat 10.1 
> > instance, where the JVM will crash almost instantly after Tomcat is done 
> > starting up.
> > The problem happens somewhat regularly, and only happens within the first 
> > minute after starting Tomcat. The solution is always to just attempt to 
> > restart Tomcat and this usually only take 1 attempt.
> >
> >
> > Tomcat is running a single web application, that sees traffic over both 
> > Websocket (several 100 clients) and Https (maybe 20-40 users during peak + 
> > a few API clients)
> >
> > Our setup is a somewhat old VM.
> > Windows Server 2016 Standard 1607, buil 14343.6351
> > Intel Xeon E5-2680 v4 @ 2.40 GHz
> > 4 x Cores
> > 8 GB Memory
> >
> > JRE version: OpenJDK Runtime Environment Temurin-17.0.8.1+1 (17.0.8.1+1) 
> > (build 17.0.8.1+1)
> > Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.8.1+1 (17.0.8.1+1, mixed 
> > mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, 
> > windows-amd64)
> >
> > Tomcat version is 10.1.15 64 bit
> >
> > The company we rent our VM servers from has installed Sentinel One that 
> > connects to the JVM through an agent. I have very little knowledge of what 
> > if anything this can do. Since this is the only thing out of the ordinary 
> > running on this setup, my fear is that this might be causing the crashes.
> 
> Some web searching suggests that is certainly likely.
> 
> > I include a partial example of the exception log here, some data may have 
> > been removed for privacy reasons. Please let med know if I should include 
> > the full file, since I've removed parts of it due to pure length.
> 
> The full file might contain a few more hints as to what went wrong.
> 
> Mark
> 

While I'm waiting for my hosting provider to disable the Sentinel Agent, I'm 
attaching a full crash report below, from another crash this morning.

> 
> >
> > #
> > # A fatal error has been detected by the Java Runtime Environment:
> > #
> > #  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x1131b169, 
> > pid=2084, tid=5160
> > #
> > # JRE version: OpenJDK Runtime Environment Temurin-17.0.8.1+1 (17.0.8.1+1) 
> > (build 17.0.8.1+1)
> > # Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.8.1+1 (17.0.8.1+1, mixed 
> > mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, 
> > windows-amd64)
> > # Problematic frame:
> > # j  
> > jakarta.servlet.http.HttpServletRequestWrapper.getDateHeader(Ljava/lang/String;)J+1
> > #
> > # Core dump will be written. Default location: 
> > E:\tomcat10\hs_err_pid2084.mdmp
> > #
> > # If you would like to submit a bug report, please visit:
> > #   https://github.com/adoptium/adoptium-support/issues
> > #
> >
> > ---  S U M M A R Y 
> >
> > Command Line: -Dcatalina.home=E:\tomcat10 -Dcatalina.base=E:\tomcat10 
> > -Dignore.endorsed.dirs=E:\tomcat10\endorsed 
> > -Djava.io.tmpdir=E:\tomcat10\temp 
> > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
> > -Djava.util.logging.config.file=E:\tomcat10\conf\logging.properties 
> > -Djava.locale.providers=COMPAT --add-opens=java.base/java.lang=ALL-UNNAMED 
> > --add-opens=java.base/java.io=ALL-UNNAMED 
> > --add-opens=java.base/java.util=ALL-UNNAMED 
> > --add-opens=java.base/java.util.concurrent=ALL-UNNAMED 
> > --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED exit abort -Xms768m 
> > -Xmx5090m -agentpath:C:\Program Files\SentinelOne\Sentinel Agent 
> > 22.3.4.612\SentinelJava64.dll
> >
> > Host: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz, 4 cores, 7G,  Windows 
> > Server 2016 , 64 bit Build 14393 (10.0.14393.5786)
> > Time: Sat Nov 11 18:18:30 2023 W. Europe Standard Time elapsed time: 
> > 153.828934 seconds (0d 0h 2m 33s)
> >
> > ---  T H R E A D  ---
> >
> > Current thread (0x2e6a9bd0):  JavaThread 
> > "https-openssl-nio-0.0.0.0-443-exec-180" daemon [_thread_in_Java, id=5160, 
> > stack(0x403a,0x404a)]
> >
> > Stack: [0x403a,0x404a],  sp=0x4049c1f8,  
> > free space=1008k
> > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> > code)
> > C  0x1131b169
> >
> >
> > siginfo: EXCEPTION_ACCESS_VIOLATION (0xc005), reading address 
> > 0x
> >
> > ...
> >
> > Stack slot to memory mapping:
> > stack at sp + 0 slots: 0x11309657 is at code_begin+1463 in an 
> > Interpreter codelet
> > return entry points  [0x113090a0, 0x11309ba0]  2816 bytes
> > stack at sp + 1 slots: 0x0061006200650077 is an unknown value
> > stack at sp + 2 slots: 0x4049c208 is pointing into the stack for 
> > thread: 0x2e6a9bd0
> > stack at sp + 3 slots: 0x2a938ae1 is pointing into