Re: [ns] TcpApp, problem killing agents

[Tarik Alj <aljtarik@cholla.inrs-telecom.uquebec.ca>]

keeping up with the debugging process, I have some news. Hence ccing the list.
when I've set a breakpoint in gdb at FullTcpAgent::usrclosed() (the call to 
close()). What happens then is a state transition from TCPS_ESTABLISHED to 
TCPS_FIN_WAIT_1, but the agent gets killed before getting FIN.

This is also apparent from the tracefile (using trace-all) : one can tell it 
couldn't complete writing to the file and I don't see none of the acks that 
should be there. I compared with and without killing the agent, in the last case 
all the acks are there but there is also a "---A----" in the 7th field, does 
anybody know what it is meant for?

many thanks,

Tarik.

  
>Date: Tue, 1 Aug 2000 14:26:02 -0700 (PDT)
>From: Haobo Yu <haoboy@isi.edu>
>To: Tarik Alj <aljtarik@cholla.inrs-telecom.uquebec.ca>
>Subject: Re: [ns] TcpApp, problem killing agents
>MIME-Version: 1.0
>
>> It seems the CBuff gets corrupted on return from process_data; the call to 
>> process_data is correctly executed. This is somehow related to the call to 
>> "done", e.g. those 2 lines :
>> 
>> $tcp proc done {} "$ns_ detach-agent $node_ $tcp; delete $tcp"
>> $tcp close
>> 
>> in my proc. I have stolen this from http-agent.tcl "Http/Client intsproc 
>> disconnect", the last 2 lines. btw, I would like to ask, is it consistent to 
>> call close after done? Shouldn't close be called before the agent is detached 
>> and deleted?
>
>That done{} is only a _declaration_; it's only executed when the tcp agent
>finishes all data transfer. That close{} call simply puts the tcp agent to
>the active close state so that it no longer delivers data.
>
>> Also, the core dump isn't systematic, for example if I add a "puts" in the 
proc; 
>> then I don't get the core dump anymore. Same if I use printfs in 
TcpApp::recv. 
>> This strongly hints for memory corruption in my opinion.
>
>Yes I'd say that this is some memory corruption. I'd suspect that you've
>deleted some tcp agent while there're still packets destined for them
>somehow. I've met this kind of problem before, and I got rid of it by
>putting delete inside that done{}. However, full-tcp agent is still very
>buggy and certainly needs more work.
>
>- Haobo