Bug 913

Summary: Queue Enqueue/Drop trace sources behavior unintuitive
Product: ns-3 Reporter: Tom Henderson <tomh>
Component: devicesAssignee: ns-bugs <ns-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: craigdo
Priority: P3    
Version: pre-release   
Hardware: All   
OS: All   
Attachments: Patch to fix enqueue trace

Description Tom Henderson 2010-05-16 23:56:53 UTC 
Reported by Dani Camps here:
http://mailman.isi.edu/pipermail/ns-developers/2010-May/007965.html

bool 
Queue::Enqueue (Ptr<Packet> p)
{
  NS_LOG_FUNCTION (this << p);
  NS_LOG_LOGIC ("m_traceEnqueue (p)");

  m_traceEnqueue (p);

  bool retval = DoEnqueue (p);
  if (retval)
    {
        ...
    }
  return retval;
}

Issues here:
- if DoEnqueue fails, m_traceEnqueue still logs a trace.  This is in contrast to the documentation that states that the trace is only hit if the packet successfully enqueues

- if there is in fact a drop (e.g. overflow), the drop trace is not triggered
Comment 1 Craig Dowell 2010-05-17 02:18:01 UTC 
Created attachment 869 [details]
Patch to fix enqueue trace
Comment 2 Craig Dowell 2010-05-17 02:19:29 UTC 
> if there is in fact a drop (e.g. overflow), the drop trace is not triggered

the drop trace is triggered by the subclass (e.g. DroptailQueue) calling Queue::Drop.

I think the attachment may do the trick.
Comment 3 Tom Henderson 2010-05-17 08:48:56 UTC 
(In reply to comment #2)
> > if there is in fact a drop (e.g. overflow), the drop trace is not triggered
> 
> the drop trace is triggered by the subclass (e.g. DroptailQueue) calling
> Queue::Drop.

OK, I see this now.

> 
> I think the attachment may do the trick.

Agree, +1.
Comment 4 Craig Dowell 2010-05-17 10:33:03 UTC 
fixed in changeset 6ac5cd5ec178