On Feb 7, 5:03 pm, Henry Townsend <henry.towns...@not.here> wrote:
> Harry Ebbers wrote:
> > Ok, but how do we obtain the pid of the process which is killing the
> > child-process? (That is part of the problem)
> > We don't know which process is doing it.
>
> How do you know the "child-process" is being *killed* at all, as opposed
> to dying on its own? He didn't say to run truss on the killing process,
> he said to run it on the process that's being killed.
>
> Find the pid of the child process while it's still running and attach
> truss to it (with the -p flag). Save the output in a file (with the -o
> flag) and wait for it to go away. The last few lines of the truss log
> should show what happened, if it caught a signal or just exited. As for
> whether the sender of the signal is identified by truss, I don't
> remember. But truss will definitely provide some very useful evidence
> even if it doesn't deliver the smoking gun.
>
> If the above method is difficult, an alternative is to take the "child
> process" executable and move it aside, e.g. "mv child child.exe". Then
> place the following shell script at the original location:
>
> #!/bin/sh
> exec truss -o /var/tmp/truss.$$.log child.exe "$@"
>
> Now the child will always run with truss logging on. You just have to
> remember to undo this later.
>
> HT


You asked why we are certain that the process is not dying on itself.
We are not 100% certain, but it uses a XtAppMainLoop loop and no
XtAppSetExitFlag is being set anywhere in our application. It is not
the only process which uses XtAppMainLoop, but the only one that is
dying and only at some customers. At most customers the problem is not
observed.

I will look if truss is acceptable for a diagnostic patch (due to the
environment and available disk-resources we have to be sparse with
logging)