[Tcpick-project] Race-Condition-Bug?

[Christian B. <ch...@do...>]

Hi all !

I probably found another bug in tcpick probably due to a race condition.

I use tcpick as sniffer and pipe all its output to an application  
that reads
from the pipe and splits the output to a bunch of streams.

TCPICK is started as

	tcpick -yR -h -i eth0 "port 80" | my-application

The application reads the header-line to know to which connection the  
next
data belongs and then reads the data as a block in binary mode. the  
block
size is determined by the number of bytes given in the header-line.  
Thus it
expects the data to immediately follow the header.

now i saw the following in my tcpick-stream
----begin-snip-----
XX.XX.XX.XX:www APF > YY.YY.YY.YY:47573 (1276)
16     FIN-WAIT-1     YY.YY.YY.YY:47573 > XX.XX.XX.XX:www
urn parseInt(result);

}


var startX = getLeftOffset();
----end-snip----

This makes my application strumbling :-(

As with race-conditioning the problem is hard to reproduce,  
unfortunately.

Regards,
    chris