On 26/11/2020 04:57, Christopher Schultz wrote: <snip/>
>> After a normal clean-up the parent then calls close on the two file >> descriptors associated with the pipe for a second time." > > So the child cleans them up AND the parent cleans them up? Or the parent > cleans when up twice? The child should be able to call close() as many > times as it wants and only poison itself. Does the child process ever > exit()? With the caveat that some of the below is educated guess work because the strace was configured to look at the events we were interested in so I am having to fill in some of the gaps. The parent "process" is a Java thread currently in native code in a 3rd party library. The parent creates a pipe which comes with two file descriptors. One for the read end, one for the write end. The parent process then forks. The child process now has copies of the two file descriptors. (see man fork for more details). The parent closes its fd for the write end of the pipe. The child closes its fd for the read end of the pipe. The child writes to the pipe and the parent reads from it. The child exits and closes its fd for the write end of the pipe. The parent closes its fd for the read end of the pipe. At this point all is good. All the closes completely cleanly. Everything has been shutdown properly. The two fds allocated to the parent are back in the pool any may be reused by other threads in the JVM. The parent then attempts to close the fds associated with the pipe again. For each fd, if it has not been reallocated an EBADF error occurs. If it has been reallocated, it is closed thereby breaking whatever was using it legitimately. > The parent process must be the JVM process, right? And the parent > process (this native library, running within the JVM process) > double-closes file descriptors, with some measurable delay? Correct. In the instance where I did most of the log analysis the delay was about 0.1 seconds. In other logs I did observe longer delays with what looked like a very different failure mode. > That's the > only way this could make sense. And of course it mess mess everything up > in really *really* unpredictable ways. Yep. > -chris > > PS There are some cases where calling close(int) more than one time > actually makes sense, but it's very rare. Evidently, HP-UX requires this > if close() fails in certain ways, while most other systems prohibit > double-calls to close() even when a failure occurs. So much for > portability. Anyway, my guess is that this isn't an HP-UX library ported > to Linux with a logic flaw introduced by that port. It's more likely > just an implementation bug. The original close calls don't fail so even if this were HP-UX code ported to Linux this case does not apply. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
