Well, we're missing some information leading up to this to confirm the problem, but this appears to be the important bit:
On Tue, Nov 15, 2005 at 02:19:14PM +0100, Michael Koch wrote:
> [pid 8494] execve("/usr/bin/c++filt", ["c++filt", "-s", "java"], [/* 26 vars
> */]) = 0
[...]
> [pid 8495] execve("/usr/bin/addr2line", ["addr2line", "-f", "-e",
> "/proc/8490/exe"], [/* 26 vars */]) = 0
[...]
> [pid 8490] write(12, "_ZN4java4lang11VMThrowable16fill"..., 62) = 62
> [pid 8490] read(9, <unfinished ...>
> [pid 8494] <... read resumed> "_ZN4java4lang11VMThrowable16fill"..., 4096) =
> 62
[...]
> [pid 8494] read(0, <unfinished ...>
[...]
> [pid 8495] read(0, <unfinished ...>
[...]
So as I expected, we're stuck in a deadlock with all processes waiting on
read. Whether this is a bug in c++filt or in gij-4.0 depends on what came
before the bit that was quoted: if gij-4.0 assumes c++filt's output will be
unbuffered, that's a gij-4.0 bug, but if gij-4.0 is doing something (not
shown) to set up for unbuffered output before the fork, that'd be a c++filt
bug for not behaving correctly.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
