From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686) Gecko/20030502 Galeon/1.3.4
Description of problem:
It seems OO.o does a popen, (possibly of a non-existant binary), and this causes
'strace' to hang; NPTL not withstanding.
How reproducible: Always
to Reproduce simply do:
strace -f soffice, and wait a while.
I assume the reporter meant "ooffice", not "soffice". :-)
I have reproduced this when using linuxthreads, but not when using nptl.
On my machine "LD_ASSUME_KERNEL=2.4.1 strace -f ooffice" reproduces it.
If the platform field in this report is accurate, then I think nptl will never
be used in the reporter's configuration anyway.
I'm looking into the problem.
I have a fix now in the upstream sources. FWIW, this was always broken in
strace I am pretty sure. Perhaps scheduling happenstance made it start showing up.
The problem case is when a process has multiple live children, and then one
child exits and becomes a zombie, and then the parent calls wait*.
Thanks so much for fixing this; I think you must be right, soffice is SO 6.0 on
my rh8 machine; my OO.o does no popen's so I suppose I daftly switched machine
to verify this.
A newer strace version is now available in rawhide. If the binary rpms
don't work on existing systems, then recompiling from the srpm surely will.
There will be an errata release for 8.0 and 9 at some point as well,
not sure exactly when.
Thanks for the report.