Mark,
On 11/24/20 09:56, Mark Thomas wrote:
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.
Looks pretty straightforward. Clearly not Connector/J... at least not
one with a normal configuration.
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.
Aha!
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.
+1 and +1
Reporting this privately to the vendor (by Eric) seems appropriate to me.
Strange that the library is getting a direct reference to the response's
file descriptor. That seems (to me) to be a tactical mistake in an
implementation. Then again, I'm not looking at what is actually being
accomplished, there... it may make perfect sense in context.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
