It also seems to happen for CSMA, maybe the issue is that I'm using Raw Sockets? I get the traffic I send with UDP or Packet sockets.

This should not happen and does not happen with all our test scenarios so, I have to ask: what is your test program ?

(In reply to comment #2)
> This should not happen and does not happen with all our test scenarios so, I
> have to ask: what is your test program ?

Hi, I first thought that it was because of the Point to Point link, but then I relized that everything I send with a Raw socket is not logged in Pcap traces. Do you have raw socket scenarios in your tests? I don't know how complete is this feature though (UDP sockets and Packet sockets are working OK for me)

Regards,
Damian

(In reply to comment #3)
> (In reply to comment #2)
> > This should not happen and does not happen with all our test scenarios so, I
> > have to ask: what is your test program ?
> 
> Hi, I first thought that it was because of the Point to Point link, but then I
> relized that everything I send with a Raw socket is not logged in Pcap traces.
> Do you have raw socket scenarios in your tests? I don't know how complete is
> this feature though (UDP sockets and Packet sockets are working OK for me)
> 
> Regards,
> Damian

Would you mind produce a testcase which explains how to reproduce the problem ?

I've found the bug! It has also nothing to do with raw sockets. The problem is that the destructors are not being called for all the PcapWriters, hence you don't close the streams and loose data. Create a topology with various links and enable all logging for PcapWriter and you will see that clearly.

My quick fix at this moment was adding m_writer->flush() after write in the method PcapWriter::WriteData. It works for me but performance suffers of course.

Regards,
Damian

The destructors should be invoked if you call Simulator::Destroy at the end of your simulation so, again, I have to ask for a testcase to figure out what is wrong in your code.

Created attachment 419 [details]
simulationto reproduce the bug

Created attachment 420 [details]
Also needed to reproduce

I've just attached 2 files. One is a modified myfirst.cc that creates pcap traces and logs PcapWriter events. The other is a modified udp-echo-client that creates a raw socket.

Use both together and you will see that 2 PcapWriter objects are created but only 1 is destroyed. Don't ask me why but if you use the original udp-echo-client the bug doesn't show.

Pcap files are ok in this case, but as the bug shows anyway with the lack of a destructor call I think it's enough as I already traced the problem from empty pcap files to lack of destructor call.

This problem is usually caused by a memory leak in your simulation.  If you run your script using valgrind, I suspect you will see the issue quickly.

The problem is a memory leak triggered by the lines you added in the echo client application:


      tid = TypeId::LookupByName ("ns3::Ipv4RawSocketFactory");
      Ptr<Socket> s = Socket::CreateSocket (GetNode(), tid);

The destructor from the created raw socket is not called when s goes out of scope.  This leaves a reference to the node in the socket which causes the node not to be destroyed, which in turn means that the pcap trace is not desroyed, which means the trace file is not flushed and closed.

Right now the socket you create does nothing but cause a memory leak, so either remove the lines of code above or add the following line of code to release the socket:

      s->Close ();

This begs the question of why the system is not destroying the socket when it closes down.

I think the answer in Ipv4L3Protocol is to add the following lines to DoDispose:

  for (SocketList::iterator i = m_sockets.begin (); i != m_sockets.end (); ++i)
    {
      *i = 0;
    }

Raw sockets are forgotten in the tear down ...

changeset 1c3138bce75e in ns-3 dev (for ns-3.5) fixes the Ipv4L3Protocol issue.

You can use s->close () in your application to manually close any raw sockets you create and your traces should close properly.

Please close this bug if it is resolved to your satisfaction.

I will close the bug since it's not affecting me anymore. However I think this is a pitfall waiting for other people to fall in, I see these two action items:

- If destroying everything manually is the way to go for applications udp-echo-client should do it and it doesn't. It is an example for people so it will guide them to don't clean stuff.

- If some kind of sockets are automatically deleted during tear down all of them should, or the behaviour is very unexpected.

I hope this small contribution helps.

>If some kind of sockets are automatically deleted during tear down
>all of them should, or the behaviour is very unexpected.

As I said, changeset 1c3138bce75e in ns-3 dev (for ns-3.5) fixes the problem

marking fixed

> If destroying everything manually is the way to go for applications
> udp-echo-client should do it and it doesn't. It is an example for 
> people so it will guide them to don't clean stuff.

changeset 59e19500509d in ns-3 dev (for ns-3.5) fixes the udp echo issue.