> -----Original Message----- > From: Mark Thomas <ma...@apache.org> > Sent: Tuesday, November 24, 2020 8:57 AM > To: users@tomcat.apache.org > Subject: Re: Weirdest Tomcat Behavior Ever? > > On 24/11/2020 14:11, Christopher Schultz wrote: > > On 11/20/20 11:08, Mark Thomas wrote: > > <snip/> > > >> A second look at the strace file from yesterday provided hard > >> evidence of a native library mis-using file descriptors and strong > >> circumstantial evidence linking that same library to a specific > >> instance of the observed failure. > > > > Interesting. How can you tell it's a library instead of, for example, > > the JVM itself (which is of course itself a set of native libraries). > > strace shows the .so file being accessed, then we see the process forking, a > pipe set up between the parent and child and the child calling execve on the > same .so file. After a normal clean-up the parent then calls close on the two > file descriptors associated with the pipe for a second time. > > I'm as sure as I can be without access to the source code for the .so file > that it > is mis-handling file descriptors. > > > I'm assuming that when you say "native library" you mean "some native > > component which is not a part of the core JVM". > > The .so file in question is not part of the JVM. It appears to be a > third-party > native library that ships as part of the commercial web application where the > original issue is observed. > > >> TL;DR, an issue in an external library, not a Tomcat issue. > > <snip/> > > > So does this really look like a (pretty serious) bug in a native > > library? Any idea which one? > > I'm reasonably sure but I had to make a couple of assumptions based on file > paths to ID the library. I've passed that info to Eric but until it is > confirmed it > doesn't seem right to name it on list. > > Mark >
The full evidence package was submitted to the application vendor this morning, including all relevant logs, packet captures, strace files, and the accompanying analysis (courtesy of Mark) which seems pretty conclusive. We're eager to hear their feedback. That said, I'm not too shy about mentioning the names of the suspected libraries, as long as we're clear that the cause is not confirmed, and specific about the evidence that points in that direction. I may do so in a follow-up posting. After all, we already know the names of the other major components involved--tomcat, java, and the jdbc connector. Naming the suspect libraries may do someone else a service who has a gut feeling about them but hasn't seen solid evidence to support their concerns. -Eric > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org Disclaimer : This email and any files transmitted with it are confidential and intended solely for intended recipients. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physician Select Management. Warning: Although Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
