Re: killing soffice.bin from oosplash

On 04/19/2012 03:11 PM, Michael Stahl wrote:
> On 19/04/12 13:35, Stephan Bergmann wrote:
> > On 04/17/2012 03:15 PM, Michael Stahl wrote:
> > > have oosplash forward SIGTERM to soffice.bin:
> > >
> > > http://cgit.freedesktop.org/libreoffice/core/commit/?id=946e7180be96178937e7be1b0bd7132902709a87
> >
> > The above is not a good idea.  At least with POSIX, there is no reliable
> > way for a parent process to forward to a child process a signal that the
> > parent receives.  There is always a window of time after fork(2) where
> > the forwarding will not yet happen, and there is always a window of time
> > after wait(2) where the forwarding will potentially send the signal to
> > an unrelated process.  (Yes, I know, the soffice script tries to do the
> > same, see
> > <http://compgroups.net/comp.unix.shell/sh-terminating-children-upon-sigterm/501864>
> > "sh: Terminating children upon SIGTERM" for a fruitless discussion.)
> >
> > The two processes need to communicate shutdown requests with a more
> > sophisticated protocol than trying to send a SIGTERM received by the
> > parent on to the child.
>
> the soffice.bin really should be dead by the time the JUnit test process
> exits, because otherwise the next time you try to run the test it won't
> run (and even worse will hang forever currently...), because the old
> soffice.bin is still listening on the pipe, so the new soffice.bin
> cannot listen.

That's why I prefer the test to hang when it cannot guarantee that all 
processes it (indirectly) spawned have terminated.

> the returning was intentional, so the oosplash could forward the exit
> status of soffice.bin, but considering the race condition you mentioned
> i guess hard-coding the exit status that soffice.bin would return is better.

The canonic(?) way of doing this is by resetting the signal's action to 
default and re-raising the signal from within the handler, so that the 
parent can observe that the process terminated due to a signal, but 
_exit should probably be just as fine.

> > > these increase reliability of JUnit based test infrastructure:
> > >
> > > http://cgit.freedesktop.org/libreoffice/core/commit/?id=90f7a3ada68f309a9d3201183ef552e59f9558fb
> > > http://cgit.freedesktop.org/libreoffice/core/commit/?id=228515e7783aecdb992258765554a530d6c831f3
> >
> > Not yet sure what to make of these two.  This is tricky territory, and a
> > number of potential deadlocks had deliberately been left in, on the
> > ground that (a) programmatically forcing termination of non-terminating
> > processes does not guarantee resource clean up (i.e., spawned
> > sub-processes can remain, see above), and (b) forcing termination
> > prevents debugging of the underlying deadlock.
>
> these are not about deadlocks but to kill the office process in
> situations where soffice.bin was not killed properly.

My words were not very clear.  What I meant was to try producing a 
deadlock if the test cannot guarantee that the spawned soffice has 
terminated.

> the first one was about a case where Desktop.terminate returned but
> didn't terminate (because there was some unsaved document still open).

...causing OfficeConnection.tearDown to hang?  Yes, that was 
intentional, as explained above.

> the second one was encountered when somebody removed an IDL type, and
> the unoil.jar still contained the corresponding class file, which made
> the Junit process' UNO runtime request the corresponding type over the
> UNO bridge, but the other side didn't have it in its RDB so the Java UNO
> bridge disposed itself, leading to an uncaught DisposedException here
> and a still running soffice.bin process.

...and again, a hanging OfficeConnection.tearDown, right?

Stephan