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. Thanks again.
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.