Date: Fri, 28 Jun 1996 01:49:59 GMT From: James Raynard <fhackers@jraynard.demon.co.uk> To: alk@think.com Cc: jkh@time.cdrom.com, hackers@freebsd.org Subject: Re: longstanding, woeful inadeqacy Message-ID: <199606280149.BAA09787@jraynard.demon.co.uk> In-Reply-To: <199606272030.PAA26920@compound.Think.COM> (message from Tony Kimball on Thu, 27 Jun 1996 15:30:57 -0500 (CDT))
next in thread | previous in thread | raw e-mail | index | archive | help
> : > Easier in what sense? It is essentially impossible to debug anything > : > that forks, since by the time you can attach to it, it has gone > : > veering wildly out of control. > : > : Not if you put a sleep loop in it > > And if I don't have source code? Or a compiler? > Or if the insertion of the sleep loop fixes the compiler bug > which I was trying to find in the first place? UT(K)SL and move the sleep loop into the exec() system call? > Or if the sleep loop prevents the process from meeting a > synchronization constraint which makes it impossible to > debug the original execution profile? Hmm. Maybe you could replace the exec()'d program with a wrapper that ktrace's it... Seriously though, it would be nice to get something like strace working for these cases, but /proc doesn't support features like system call tracing. -- James Raynard, Edinburgh, Scotland james@jraynard.demon.co.uk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606280149.BAA09787>