Thanks for the valuable information and debugging info. It's very
strange that the bug is gone in the newer version even though we can't
figure out what would have caused that bug in the things that we
changed.

I don't suppose that your Internet path is wide enough to transfer that
file to us for debugging, is it?

> On Tue, Nov 09, 2004 at 01:35:11PM +0100, Lennert Buytenhek wrote:
>
> > > That would be very helpful if you could get the chance.
> >
> > OK. The old version (6.6.1) is still running after ~15 hours, and
> > the status is such:
> > - 900 consumed CPU minutes (while 6.6.7 finishes in ~40 minutes.)
> > - Memory footprint is 400M.
> > - ~280M is memory-resident, the rest has been swapped out (~120M swap
> > space in use.)
> > - vmstat reports zero swapins/swapouts over a 5 minute period, so those
> > 120M are really not being touched.
> >
> > So it would appear that it's looping somewhere. It's definitely not
> > trashing.
>
> I have to kill the process now, as there are other people wanting to
> use this machine.
>
> Just as a test, I ran an app alongside tcptrace that consumes all memory
> and eventually gets killed due to out-of-memory. This has forced most
> of tcptrace's process image to be swapped out. Right now it's looking
> like this:
>
> # ps axuw | grep tcptrace
> root 17889 60.3 0.0 408020 388 pts/3 R Nov08 1108:46 tcptrace-6.6.1 -ln hdr
>
> The process image is 408M, and the resident set size is only 388kB!
> Checking the swap numbers, there is 418M swap in use, so indeed, most
> of tcptrace has been swapped out.
>
> But, it's still running at 100% CPU (after 1110 CPU minutes, whereas
> 6.6.7 completes in ~40 minutes), and vmstat again shows zero swapins
> and swapouts.
>
> So it appears to be that tcptrace is infinitely looping while touching
> only 388 kilobytes of its address space. This would indeed indicate it's
> stuck in a rather tight loop somewhere.
>
> Hope this was of help.
>
>
> cheers,
> Lennert