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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
