[ns] bug in Tcp tracevar behaviour?

[Chris Develder <chris.develder@intec.rug.ac.be>]

Hi,

I'm using ns2.1b8, my system:
- Linux 2.2.17 (gcc version 2.95.2 20000220 (Debian GNU/Linux))
- Detected 1008995 kHz processor.
- Memory: 257892k/262016k available (884k kernel code, 412k reserved, 2788k 
data, 40k init)
- CPU: L1 I Cache: 64K  L1 D Cache: 64K
- CPU: L2 Cache: 256K
- CPU: AMD Athlon(tm) Processor stepping 02C

Now, what I think is a bug: when i use 'tracevar' from Agent/TCP, I get a 
timestamp different from 0.00000 for the _first_ occurence of the traced 
variable (e.g 3.88639), so for its _initial_ value. Any later values (output 
produced during run) have correct timestamp. However, sometimes everything 
works just fine....

I use following ns commands in my simulation script (tcl file; see attachment)
	...
	$tcp_src($name) attach-trace $outfile(trace,tcp)
	$tcp_src($name) tracevar cwnd_
	...
	$tcp_src($name) tracevar ndatabytes
	...

(note that i attach the trace _before_ actually issuing tracevar command)
When i look at the output of the trace i sometimes see the correct behaviour:
# in trace; file produced by ns
0.00000  16 1  7  81 cwnd_ 1.000 
...
0.00000  16 1  7  81 ndatabytes_ 0
...
0.50499  9  6  7  16 ndatabytes_ 40
...
0.53627  9  6  7  16 cwnd_ 2.000
...

However sometimes (other simulation parameters), I get things like
# in trace; file produced by ns
4272430623239427242535818257791804523335416217504940005161915605379257937698926894682928512029555513487597639066179510154065109288203500356608936713161140280344932866750703667773440.00000 
16 1  7  81 cwnd_ 1.000
...

or a less exotic value, like 
3.88639  16 1  7  81 cwnd_ 1.000 

Does someone have an idea what could be causing this?? (Probably bug is in 
TracedVar classes or something...; i.e. maybe fault of OTcl rather than ns 
itself?)

Kind regards,
Chris.