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