From code at nsnam.ece.gatech.edu Thu Oct 1 01:31:03 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 01 Oct 2009 04:31:03 -0400
Subject: [Ns-bugs] [Bug 698] New: tcp testcase crashes at end of testcase
simulation
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=698
Summary: tcp testcase crashes at end of testcase simulation
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: internet-stack
AssignedTo: ns-bugs at isi.edu
ReportedBy: mathieu.lacage at sophia.inria.fr
Estimated Hours: 0.0
in src/internet-stack/tcp-test.cc, uncomment line 336 and witness the tcp
testcase crashing. I did not debug this seriously, but this looks like a socket
lifetime bug.
Here is the end of the debug log NS_LOG=TcpSocketImpl:TcpL4Protocol
0s TcpL4Protocol:Receive(): TcpL4Protocol 0x9b750b8 receiving seq 100001 ack
100001 flags 10 data size 20
0s TcpL4Protocol:Receive(): TcpL4Protocol 0x9b750b8 received a packet
0s TcpL4Protocol:Receive(): TcpL4Protocol 0x9b750b8 forwarding up to
endpoint/socket
0s TcpSocketImpl:ForwardUp(): Socket 0x9b73728 got forward up dport 49153 daddr
192.168.1.2 sport 50000 saddr 192.168.1.1
0s TcpSocketImpl:ForwardUp(0x9b73728, 0x9bbe8a8, 192.168.1.1, 50000)
0s TcpL4Protocol:FlagsEvent(0x9b73920, )
0s TcpSocketImpl:ProcessEvent(0x9b73728, 6)
0s TcpSocketImpl:ProcessEvent(): TcpSocketImpl 0x9b73728 processing event 6
0s TcpL4Protocol:Lookup(0x9b73920, 6, 6)
0s TcpSocketImpl:ProcessEvent(): TcpSocketImpl::ProcessEvent stateAction 13
0s TcpSocketImpl:ProcessEvent(): TcpSocketImpl 0x9b73728 moved from state 6 to
state 0
0s TcpSocketImpl:ProcessEvent(): TcpSocketImpl 0x9b73728 pendingData 0
0s TcpSocketImpl:ProcessEvent(): TcpSocketImpl 0x9b73728 transition to CLOSED
from 0 event 6 closeNot 0 action 13
0s TcpSocketImpl:ProcessEvent(): TcpSocketImpl 0x9b73728 calling Closed from PE
origState 6 event 6
0s TcpSocketImpl:ProcessEvent(): TcpSocketImpl 0x9b73728 transition to CLOSED
from 0 event 6 set CloseNotif
0s TcpL4Protocol:DeAllocate(0x9b73668, 0x9b73970)
0s TcpSocketImpl:ForwardUp(): Socket 0x9b73728 processing pkt action, 13
current state 0
0s TcpSocketImpl:ProcessPacketAction(0x9b73728, 13, 0x9bbe8a8,
05-06-c0:a8:01:01:50:c3)
0s TcpSocketImpl:ProcessAction(0x9b73728, 13)
0s TcpSocketImpl:ProcessAction(): TcpSocketImpl 0x9b73728 Action APP_CLOSED
0s TcpSocketImpl:ReTxTimeout(0x9b74108)
0s TcpSocketImpl:ReTxTimeout(): 0x9b74108 ReTxTimeout Expired at time 0
0s TcpSocketImpl:Window()
0s TcpSocketImpl:Window(): TcpSocketImpl::Window() 0x9b74108
0s TcpSocketImpl:Retransmit(0x9b74108)
0s TcpSocketImpl:Retransmit(): TcpSocketImpl 0x9b74108 retxing seq 99361
0s TcpSocketImpl:Retransmit(): 0x9b74108 Schedule ReTxTimeout at time 0 to
expire at time 0
0s TcpL4Protocol:SendPacket(): TcpL4Protocol 0x9b750b8 sending seq 99361 ack
100002 flags 0 data size 536
0s TcpL4Protocol:SendPacket(0x9b750b8, 0x9bbe8a8, 192.168.1.1, 192.168.1.2)
0s TcpL4Protocol:Receive(0x9b73668, 0x9bbe868, 192.168.1.1, 192.168.1.2,
0x9b730b8)
0s TcpL4Protocol:Receive(): TcpL4Protocol 0x9b73668 receiving seq 99361 ack
100002 flags 0 data size 556
0s TcpL4Protocol:Receive(): TcpL4Protocol 0x9b73668 received a packet
0s TcpL4Protocol:Receive(): No endpoints matched on TcpL4Protocol 0x9b73668
0s TcpL4Protocol:Receive(): destination IP: 192.168.1.2 destination port:
49153 source IP: 192.168.1.1 source port: 50000
and backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x01124056 in ns3::Callback, ns3::Ipv4Address,
unsigned short, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty,
ns3::empty>::operator() (this=0x807c990, a1={m_ptr = 0x81bd008}, a2={m_address
= 3232235777}, a3=50000)
at debug/ns3/callback.h:429
429 return (*(DoPeekImpl ())) (a1,a2,a3);
Missing separate debuginfos, use: debuginfo-install libxcb-1.1.91-7.fc10.i386
libxml2-2.7.3-2.fc10.i386
(gdb) bt
#0 0x01124056 in ns3::Callback, ns3::Ipv4Address,
unsigned short, ns3::empty, ns3::empty, ns3::empty, ns3::empty, ns3::empty,
ns3::empty>::operator() (this=0x807c990, a1={m_ptr = 0x81bd008}, a2={m_address
= 3232235777}, a3=50000)
at debug/ns3/callback.h:429
#1 0x01123859 in ns3::Ipv4EndPoint::DoForwardUp (this=0x807c980, p={m_ptr =
0x81bd008}, saddr={m_address = 3232235777}, sport=50000)
at ../src/internet-stack/ipv4-end-point.cc:106
#2 0x01123a02 in Notify (this=0x81b8810) at debug/ns3/make-event.h:167
#3 0x00f505b2 in ns3::EventImpl::Invoke (this=0x81b8810) at
../src/simulator/event-impl.cc:39
#4 0x00f6f949 in ns3::DefaultSimulatorImpl::ProcessOneEvent (this=0x807e030)
at ../src/simulator/default-simulator-impl.cc:113
#5 0x00f6f9a6 in ns3::DefaultSimulatorImpl::Run (this=0x807e030) at
../src/simulator/default-simulator-impl.cc:143
#6 0x00f58c3b in ns3::Simulator::Run () at ../src/simulator/simulator.cc:160
#7 0x010f4448 in ns3::TcpTestCase::DoRun (this=0x805e798) at
../src/internet-stack/tcp-test.cc:144
#8 0x00c615bf in ns3::TestCase::Run (this=0x805e798) at
../src/core/test.cc:151
#9 0x00c622fc in ns3::TestSuite::DoRun (this=0x1775420) at
../src/core/test.cc:606
#10 0x00c61350 in ns3::TestSuite::Run (this=0x1775420) at
../src/core/test.cc:412
#11 0x08049e2e in main (argc=3, argv=0xbffff384) at ../utils/test-runner.cc:251
(gdb)
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 1 02:24:41 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 01 Oct 2009 05:24:41 -0400
Subject: [Ns-bugs] [Bug 669] main-packet-printer broken
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=669
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria.
| |fr
--- Comment #1 from Mathieu Lacage 2009-10-01 05:24:41 EDT ---
I would like to suggest to kill this code. There is already sample code which
shows how to do this in src/common/packet.cc Packet::Print
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 1 04:29:51 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 01 Oct 2009 07:29:51 -0400
Subject: [Ns-bugs] [Bug 699] New: TestCase::DoRun probably should not return
a bool
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=699
Summary: TestCase::DoRun probably should not return a bool
Product: ns-3
Version: pre-release
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: simulation core
AssignedTo: ns-bugs at isi.edu
ReportedBy: mathieu.lacage at sophia.inria.fr
Estimated Hours: 0.0
It would be simpler for all testcases if we did not have to return something
and merely used the status of TestCase::m_error as set by ReportFailure.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 1 04:53:26 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 01 Oct 2009 07:53:26 -0400
Subject: [Ns-bugs] [Bug 695] DcfManager::UpdateBackoff () uses slow
HighPrecision::Div()
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=695
Pavel Boyko changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |boyko at iitp.ru
--- Comment #5 from Pavel Boyko 2009-10-01 07:53:26 EDT ---
(In reply to comment #0)
> UpdateBackoff() function seems to be a bottleneck for wifi-based simulations
> eating up to 30% in "examples/mesh".
Mathieu, could you explain me why do we need 128 bits for time at all? We
always find high precision arithmetics on top of the profiles (oprofile,
cachegrind) -- can we try to avoid them using "native" 64 bit time? More
globally, I have an impression that ns-3 is too slow to practically simulate
O(100) wifi stations with dense traffic -- do you agree?
> The really slow line is (src/devices/wifi/dcf-manager.cc:522 at rev
> 684768c10c59):
> Scalar nSlots = (Simulator::Now () - backoffStart) / m_slotTime;
>
> This line executes slow HighPrecision division each time the Updatebackoff()
> function is called (and moreover each for() loop iteration).
>
> I see at least 2 possible solutions:
> 1) retrieve nanoseconds from all involved Time variables and run all
> calculations using long double precision;
> 2) Calculate (1 / m_slotTime) once in DcfManager::SetSlot() and use faster
> 128bit multiplication instead of slow 128bit devision here.
>
> Solution #1 theoretically can be less precise than original code, but:
> 1) GetNanoSeconds () returns uint64_t which won't overflow until 584-year-long
> simulation which is more than enough;
> 2) difference (Simulator::Now () - backoffStart) isn't supposed to be very
> large, so long double easily handles it;
> 3) ratio ((Simulator::Now () - backoffStart) / m_slotTime) isn't supposed to be
> very large too, so again long double is enough;
> 4) nSlots is anyway converted to double, thus losing the HighPrecision.
> So I think solution #1 isn't less precise in practice.
>
> Solution #2 gives less runtime speed up than solution #1, but is still as
> precise as original code.
>
> All unit tests and regression tests are passed for both solutions.
> Personally I vote for solution #1.
>
> More detailed benchmarks and patches will be posted soon.
>
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 1 05:43:47 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 01 Oct 2009 08:43:47 -0400
Subject: [Ns-bugs] [Bug 700] New: aAirPropagationTime is not added to a slot
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=700
Summary: aAirPropagationTime is not added to a slot
Product: ns-3
Version: pre-release
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: wifi
AssignedTo: ns-bugs at isi.edu
ReportedBy: andreev at iitp.ru
Estimated Hours: 0.0
Created an attachment (id=614)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=614)
Propsed fix (no testcase)
Slot time shall be corrected by propagation delay in the same manner as CTS and
ACK timeouts, i.e 2*GetDefaultMaxPropagationDelay () shall be added in types of
standard. Path is applied.
Also I think, that it is worth to make a convinient attribute of propagation
delay with virtual getters and setters (like SetSlot) of WifiMac class.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 1 05:50:25 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 01 Oct 2009 08:50:25 -0400
Subject: [Ns-bugs] [Bug 700] aAirPropagationTime is not added to a slot
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=700
Kirill Andreev changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #614 is|0 |1
obsolete| |
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 1 05:49:47 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 01 Oct 2009 08:49:47 -0400
Subject: [Ns-bugs] [Bug 700] aAirPropagationTime is not added to a slot
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=700
--- Comment #1 from Kirill Andreev 2009-10-01 08:49:47 EDT ---
Created an attachment (id=615)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=615)
Proposed fix
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 1 05:55:34 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 01 Oct 2009 08:55:34 -0400
Subject: [Ns-bugs] [Bug 700] aAirPropagationTime is not added to a slot
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=700
Andrey Mazo changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mazo at iitp.ru
--- Comment #2 from Andrey Mazo 2009-10-01 08:55:34 EDT ---
(In reply to comment #0)
> Created an attachment (id=614)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=614) [details]
> Propsed fix (no testcase)
>
> Slot time shall be corrected by propagation delay in the same manner as CTS and
> ACK timeouts, i.e 2*GetDefaultMaxPropagationDelay () shall be added in types of
> standard. Path is applied.
s/in types of standard/for all 802.11{a,b,g} standard/
s/Path is applied/Patch is attached/
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 1 08:01:22 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 01 Oct 2009 11:01:22 -0400
Subject: [Ns-bugs] [Bug 701] New: inline HighPrecision Max () and Min ()
functions
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=701
Summary: inline HighPrecision Max () and Min () functions
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P3
Component: simulation core
AssignedTo: ns-bugs at isi.edu
ReportedBy: mazo at iitp.ru
Estimated Hours: 0.0
0) Original code
Command being timed: "build/optimized/examples/wifi-wired-bridging --nStas=4"
User time (seconds): 403.23
System time (seconds): 5.57
Percent of CPU this job got: 98%
Elapsed (wall clock) time (h:mm:ss or m:ss): 6:55.31
Command being timed: "build/optimized/examples/mesh"
User time (seconds): 256.20
System time (seconds): 0.02
Percent of CPU this job got: 99%
Elapsed (wall clock) time (h:mm:ss or m:ss): 4:16.49
1) Modified code
Command being timed: "build/optimized/examples/wifi-wired-bridging --nStas=4"
User time (seconds): 389.68
System time (seconds): 5.76
Percent of CPU this job got: 98%
Elapsed (wall clock) time (h:mm:ss or m:ss): 6:41.36
Command being timed: "build/optimized/examples/mesh"
User time (seconds): 232.67
System time (seconds): 0.03
Percent of CPU this job got: 99%
Elapsed (wall clock) time (h:mm:ss or m:ss): 3:52.83
So, we're getting about 3-10% speed improvement.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 1 08:02:16 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 01 Oct 2009 11:02:16 -0400
Subject: [Ns-bugs] [Bug 701] inline HighPrecision Max () and Min () functions
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=701
--- Comment #1 from Andrey Mazo 2009-10-01 11:02:16 EDT ---
Created an attachment (id=616)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=616)
Proposed patch
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 1 08:13:14 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 01 Oct 2009 11:13:14 -0400
Subject: [Ns-bugs] [Bug 701] inline HighPrecision Max () and Min () functions
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=701
Andrey Mazo changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mazo at iitp.ru
--- Comment #2 from Andrey Mazo 2009-10-01 11:13:14 EDT ---
(In reply to comment #0)
> So, we're getting about 3-10% speed improvement.
Forgot to say, that:
1) revision -- 0ba73cdd2a43
2) compiler -- gcc-4.3.2
3) build -- static optimized
4) machine -- Intel Xeon @ 2.80GHz
5) examples are modified with attachment 608 from bug 695 [1]
[1] http://www.nsnam.org/bugzilla/attachment.cgi?id=608
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 1 21:34:26 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 02 Oct 2009 00:34:26 -0400
Subject: [Ns-bugs] [Bug 702] New: Make global routing robust to link/device
events
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=702
Summary: Make global routing robust to link/device events
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: routing
AssignedTo: tomh at tomh.org
ReportedBy: tomh at tomh.org
CC: ns-bugs at isi.edu
Estimated Hours: 0.0
Implement Ipv4GlobalRouting::Notify* methods
Now that we have these methods, we can make global routing robust to these
events. Presently, it is documented that the user must call
RecomputeRoutingTables() when topology changes. See
examples/dynamic-global-routing.cc. This could be automated by implementing
the Notify methods.
Also, remove NS_DEPRECATED methods in global-route-manager.h
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 1 21:36:46 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 02 Oct 2009 00:36:46 -0400
Subject: [Ns-bugs] [Bug 703] New: Make OLSR robust to link/device events
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=703
Summary: Make OLSR robust to link/device events
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: routing
AssignedTo: ns-bugs at isi.edu
ReportedBy: tomh at tomh.org
Estimated Hours: 0.0
similar to bug 702
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 1 22:31:01 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 02 Oct 2009 01:31:01 -0400
Subject: [Ns-bugs] [Bug 704] New: ns3-wifi-propagation-loss-models
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=704
Summary: ns3-wifi-propagation-loss-models
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P1
Component: wifi
AssignedTo: tomh at tomh.org
ReportedBy: tomh at tomh.org
CC: ns-bugs at isi.edu
Estimated Hours: 0.0
Failing test among the new wifi tests checked in recently.
FAIL: Test Suite "ns3-wifi-propagation-loss-models" (real 0.04 user 0.03 system
0.00)
PASS: Test Case "Check to see that the ns-3 Friis propagation loss model
provides correct SNR values" (real 0.03 user 0.02 system 0.00)
FAIL: Test Case "Check to see that the ns-3 Log Distance propagation loss model
provides correct SNR values" (real 0.01 user 0.01 system 0.00)
Details:
Message: Got unexpected SNR value
Condition: snr (actual) < testVector.m_snr (limit) + testVector.m_tolerance
(tol) && snr (actual) > testVector.m_snr (limit) - testVector.m_tolerance (tol)
Actual: 176.395
Limit: 176.407 +- 0.0005
File: ../src/test/ns3wifi/propagation-loss-models-test-suite.cc
Line: 360
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 1 22:32:35 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 02 Oct 2009 01:32:35 -0400
Subject: [Ns-bugs] [Bug 669] main-packet-printer broken
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=669
--- Comment #2 from Tom Henderson 2009-10-02 01:32:35 EDT ---
OK with me.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 1 22:55:37 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 02 Oct 2009 01:55:37 -0400
Subject: [Ns-bugs] [Bug 407] OLSR is missing HNA support
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=407
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P1 |P2
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 2 00:32:51 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 02 Oct 2009 03:32:51 -0400
Subject: [Ns-bugs] [Bug 648] Missing Doxygen for Several Helpers
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=648
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|ns-bugs at isi.edu |tomh at tomh.org
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 2 00:39:03 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 02 Oct 2009 03:39:03 -0400
Subject: [Ns-bugs] [Bug 612] example scripts
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=612
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|ns-bugs at isi.edu |craigdo at ee.washington.edu
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 2 00:39:46 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 02 Oct 2009 03:39:46 -0400
Subject: [Ns-bugs] [Bug 669] main-packet-printer broken
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=669
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|ns-bugs at isi.edu |craigdo at ee.washington.edu
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 2 11:18:20 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 02 Oct 2009 14:18:20 -0400
Subject: [Ns-bugs] [Bug 555] DCF immediate access bug
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=555
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |craigdo at ee.washington.edu
Severity|normal |critical
Priority|P1 |P2
--- Comment #14 from Craig Dowell 2009-10-02 14:18:19 EDT ---
On the critical path for ns-3.7
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 2 11:20:12 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 02 Oct 2009 14:20:12 -0400
Subject: [Ns-bugs] [Bug 407] OLSR is missing HNA support
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=407
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
Priority|P2 |P4
--- Comment #4 from Craig Dowell 2009-10-02 14:20:12 EDT ---
Stop priority oscillations.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 2 11:30:03 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 02 Oct 2009 14:30:03 -0400
Subject: [Ns-bugs] [Bug 426] TCP: close does not send RST
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=426
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |blocker
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 2 11:29:48 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 02 Oct 2009 14:29:48 -0400
Subject: [Ns-bugs] [Bug 424] TCP FIN notification callback needed
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=424
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |blocker
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 2 11:31:09 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 02 Oct 2009 14:31:09 -0400
Subject: [Ns-bugs] [Bug 645] [patch] fixes for opening stats file with
OMNeT++
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=645
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |blocker
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 2 11:32:00 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 02 Oct 2009 14:32:00 -0400
Subject: [Ns-bugs] [Bug 645] [patch] fixes for opening stats file with
OMNeT++
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=645
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|blocker |enhancement
Priority|P1 |P3
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 2 11:35:15 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 02 Oct 2009 14:35:15 -0400
Subject: [Ns-bugs] [Bug 664] memory fault/dangling pointer problems in
tcp-socket-impl.cc, with suggested fixes
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=664
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |blocker
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 2 11:37:16 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 02 Oct 2009 14:37:16 -0400
Subject: [Ns-bugs] [Bug 704] ns3-wifi-propagation-loss-models
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=704
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |craigdo at ee.washington.edu
Severity|normal |minor
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 2 11:36:36 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 02 Oct 2009 14:36:36 -0400
Subject: [Ns-bugs] [Bug 689] default energy detection threshold is not useful
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=689
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |craigdo at ee.washington.edu
Severity|normal |minor
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 2 11:36:58 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 02 Oct 2009 14:36:58 -0400
Subject: [Ns-bugs] [Bug 697] TCP "Sent" callback reports wrong count
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=697
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |craigdo at ee.washington.edu
Severity|normal |blocker
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 2 15:37:11 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 02 Oct 2009 18:37:11 -0400
Subject: [Ns-bugs] [Bug 689] default energy detection threshold is not useful
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=689
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|ns-bugs at isi.edu |mathieu.lacage at sophia.inria.
| |fr
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Sun Oct 4 23:05:04 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 05 Oct 2009 02:05:04 -0400
Subject: [Ns-bugs] [Bug 704] ns3-wifi-propagation-loss-models
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=704
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Tom Henderson 2009-10-05 02:05:04 EDT ---
fixed in changeset: 9c79df567f12
(made the test a unit test and relocated to src/devices/wifi)
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Mon Oct 5 07:18:31 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 05 Oct 2009 10:18:31 -0400
Subject: [Ns-bugs] [Bug 705] New: netanim code does not build on win32
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=705
Summary: netanim code does not build on win32
Product: ns-3
Version: ns-3-dev
Platform: PC
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: general
AssignedTo: ns-bugs at isi.edu
ReportedBy: gjcarneiro at gmail.com
Estimated Hours: 0.0
Created an attachment (id=618)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=618)
disable netanim if the includes are missing
netanim code does not build on win32 (mingw) due to the missing includes
(sys/socket.h for one).
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Mon Oct 5 08:06:25 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 05 Oct 2009 11:06:25 -0400
Subject: [Ns-bugs] [Bug 705] netanim code does not build on win32
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=705
Josh Pelkey changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jpelkey at gatech.edu,
| |riley at ece.gatech.edu
--- Comment #1 from Josh Pelkey 2009-10-05 11:06:25 EDT ---
This looks good to me. I'll CC Dr. Riley to make sure he sees this one.
Thanks Gustavo.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Mon Oct 5 08:14:22 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 05 Oct 2009 11:14:22 -0400
Subject: [Ns-bugs] [Bug 705] netanim code does not build on win32
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=705
--- Comment #2 from George Riley 2009-10-05 11:14:22 EDT ---
Wouldn't it be better to just #ifdef out the socket output feature of
NetAnim if the socket includes can't be found?
George
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Mon Oct 5 08:25:35 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 05 Oct 2009 11:25:35 -0400
Subject: [Ns-bugs] [Bug 705] netanim code does not build on win32
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=705
--- Comment #3 from Gustavo J. A. M. Carneiro 2009-10-05 11:25:34 EDT ---
(In reply to comment #2)
> Wouldn't it be better to just #ifdef out the socket output feature of
> NetAnim if the socket includes can't be found?
> George
>
Possibly. I do not know enough of the net-anim code to know for sure, I was
just trying to make mingw compile again. So you are telling me that net-anim
is still useful without the socket code and should still be compiled?
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Mon Oct 5 08:33:39 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 05 Oct 2009 11:33:39 -0400
Subject: [Ns-bugs] [Bug 705] netanim code does not build on win32
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=705
--- Comment #4 from Gustavo J. A. M. Carneiro 2009-10-05 11:33:39 EDT ---
Created an attachment (id=619)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=619)
start of patch
To bootstrap the second approach, here's a patch that disables the socket
includes if they are not found. But now someone more knowledgeable than me
about netanim should figure out how to disable the rest of the code that uses
sockets, and code to put as fallback.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Mon Oct 5 13:20:10 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 05 Oct 2009 16:20:10 -0400
Subject: [Ns-bugs] [Bug 705] netanim code does not build on win32
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=705
--- Comment #5 from George Riley 2009-10-05 16:20:09 EDT ---
(In reply to comment #4)
> Created an attachment (id=619)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=619) [details]
> start of patch
>
> To bootstrap the second approach, here's a patch that disables the socket
> includes if they are not found. But now someone more knowledgeable than me
> about netanim should figure out how to disable the rest of the code that uses
> sockets, and code to put as fallback.
>
I posted this reply earlier today but for some reason appears to not have
gone through. The short answer is that yes, the Animator is quite useful
without the sockets. The sockets interface simply allows an animation
to connect to a "running" simulation and display the state as the simulation
progresses. Without sockets, the animation interface can write to a file
(which I suspect is the most popular approach anyway). After the simulation
completes the animator reads the file and animates after the fact.
George
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Oct 6 06:58:34 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 06 Oct 2009 09:58:34 -0400
Subject: [Ns-bugs] [Bug 645] [patch] fixes for opening stats file with
OMNeT++
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=645
--- Comment #7 from Andras Varga 2009-10-06 09:58:34 EDT ---
I noticed this bug got categorized as "Enhancement". I think that is
misleading, because the currently generated files have problems, and cannot be
loaded into the OMNeT++ result analyser. So this issue is a bug of some sort,
and not an enhancement. Just my 2c.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Tue Oct 6 08:35:28 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 06 Oct 2009 11:35:28 -0400
Subject: [Ns-bugs] [Bug 706] New: Backoff counting when starting NS.
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=706
Summary: Backoff counting when starting NS.
Product: ns-3
Version: pre-release
Platform: All
OS/Version: All
Status: NEW
Severity: minor
Priority: P5
Component: wifi
AssignedTo: ns-bugs at isi.edu
ReportedBy: andreev at iitp.ru
Estimated Hours: 0.0
Created an attachment (id=621)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=621)
Proposed fix.
When the packet is received, DcaTxop must start backoff immediately, but when
we initiate our simulation, the backoff is not counted. So, I suppose to add
starting backoff in constructor of DcaTxop and in SetMinCw method, because
inside constructor MinCw may be incorrect.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Oct 6 11:22:56 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 06 Oct 2009 14:22:56 -0400
Subject: [Ns-bugs] [Bug 694] compilation of src/simulator/time.cc with gcc
eats up to 1.4G of RAM
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=694
Andrey Mazo changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mazo at iitp.ru
--- Comment #1 from Andrey Mazo 2009-10-06 14:22:56 EDT ---
(In reply to comment #0)
> Compilation of time.cc eats up to 1.4G of RAM and about 5 minutes with
> gcc-4.3.2 and gcc-4.4.1 (not tested on other compilers yet).
> This makes the whole compilation of ns-3 nearly impossible on low-memory
> machines.
changeset d0b9a6e08e47 workarounds this problem.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Oct 6 20:50:05 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 06 Oct 2009 23:50:05 -0400
Subject: [Ns-bugs] [Bug 707] New: new build fail ,open solaris
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=707
Summary: new build fail ,open solaris
Product: ns-3
Version: pre-release
Platform: PC
OS/Version: Other
Status: NEW
Severity: normal
Priority: P5
Component: general
AssignedTo: ns-bugs at isi.edu
ReportedBy: quantummov at gmail.com
Estimated Hours: 0.0
salil at lpsolaris:~/Documents/ns-allinone-3.5.1# python build.py
# Build NSC
Entering directory `nsc-0.5.1'
=> python scons.py linux-2.6.18
scons: Reading SConscript files ...
OSError: Unsupported architecture, if you want to crosscompile, use "scons
target=x86" (or amd64):
File "/export/home/salil/Documents/ns-allinone-3.5.1/nsc-0.5.1/SConstruct",
line 126:
if not conf.get_target_architecture():
File
"/export/home/salil/Documents/ns-allinone-3.5.1/nsc-0.5.1/scons-local-1.2.0.d20090223/SCons/SConf.py",
line 647:
ret = apply(self.test, (context,) + args, kw)
File "/export/home/salil/Documents/ns-allinone-3.5.1/nsc-0.5.1/SConstruct",
line 69:
raise OSError, ('Unsupported architecture, if you want to '
Checking target architecure...# Build NSC: failure (ignoring NSC)
Leaving directory `nsc-0.5.1'
# Build NS-3
Entering directory `ns-3.5.1'
Note: configuring ns-3 without NSC
=> python waf configure --with-regression-traces ../ns-3.5.1-ref-traces
--with-pybindgen ../pybindgen-0.10.0.640
Checking for program g++ : ok /usr/bin/g++
Checking for program cpp : not found
Checking for program ar : ok /usr/bin/ar
Checking for program ranlib : ok /usr/bin/ranlib
Checking for g++ : ok
Checking for program pkg-config : not found
Checking for regression traces location : ok ../ns-3.5.1-ref-traces (given)
Checking for -Wno-error=deprecated-declarations support : no
Checking for header stdlib.h : ok
Checking for header signal.h : ok
Checking for header pthread.h : ok
Checking for high precision time implementation : 128-bit integer
Checking for header stdint.h : ok
Checking for header inttypes.h : ok
Checking for header sys/inttypes.h : ok
Checking for library rt : ok
Checking for header netpacket/packet.h : not found
Checking for header linux/if_tun.h : not found
Checking for library sqlite3 : ok
Checking for NSC location : not found
Checking for program python : ok /usr/bin/python
Checking for Python version >= 2.3 : ok 2.4.4
Checking for library python2.4 : ok
Checking for program python2.4-config : not found
Checking for program python-config-2.4 : not found
Checking for header Python.h : ok
Checking for pybindgen location : ok
../pybindgen-0.10.0.640 (given)
Checking for Python module pybindgen : ok
Checking for pybindgen version : ok 0.10.0.640
Checking for Python module pygccxml : not found
Checking for program sudo : ok /usr/bin/sudo
Checking for program hg : ok /usr/bin/hg
Checking for program valgrind : not found
---- Summary of optional NS-3 features:
Threading Primitives : enabled
Real Time Simulator : enabled
Emulated Net Device : not enabled ( include not
detected)
GNU Scientific Library (GSL) : not enabled (GSL not found)
Tap Bridge : not enabled ( include not
detected)
GtkConfigStore : not enabled (library 'gtk+-2.0 >= 2.12' not
found)
XmlIo : not enabled (library 'libxml-2.0 >= 2.7' not
found)
SQlite stats data output : enabled
Network Simulation Cradle : not enabled (NSC not found (see option
--with-nsc))
Python Bindings : enabled
Python API Scanning Support : not enabled (Missing 'pygccxml' Python module)
Use sudo to set suid bit : not enabled (option --enable-sudo not selected)
Static build : not enabled (option --enable-static not
selected)
'configure' finished successfully (6.981s)
=> python waf
Waf: Entering directory
`/export/home/salil/Documents/ns-allinone-3.5.1/ns-3.5.1/build'
[293/677] cxx: src/core/names.cc -> build/debug/src/core/names_1.o
g++: unrecognized option `-pthread'
In file included from debug/ns3/simulator.h:27,
from ../src/core/names.cc:25:
debug/ns3/nstime.h:42: error: expected identifier before numeric constant
debug/ns3/nstime.h:42: error: expected `}' before numeric constant
debug/ns3/nstime.h:42: error: expected unqualified-id before numeric constant
debug/ns3/nstime.h:42: error: expected `,' or `;' before numeric constant
debug/ns3/nstime.h:53: error: variable or field `Set' declared void
debug/ns3/nstime.h:53: error: `precision_t' was not declared in this scope
debug/ns3/nstime.h:57: error: `precision_t' does not name a type
debug/ns3/nstime.h:119: error: expected `)' before "data"
debug/ns3/nstime.h:149: error: ISO C++ forbids declaration of `HighPrecision'
with no type
debug/ns3/nstime.h:149: error: expected `;' before "const"
debug/ns3/nstime.h:150: error: ISO C++ forbids declaration of `HighPrecision'
with no type
debug/ns3/nstime.h:150: error: expected `;' before '*' token
debug/ns3/nstime.h:153: error: `HighPrecision' does not name a type
debug/ns3/nstime.h: In constructor `TimeUnit::TimeUnit()':
debug/ns3/nstime.h:158: error: class `TimeUnit' does not have any field
named `m_data'
debug/ns3/nstime.h: In copy constructor `TimeUnit::TimeUnit(const
TimeUnit&)':
debug/ns3/nstime.h:162: error: class `TimeUnit' does not have any field
named `m_data'
debug/ns3/nstime.h: In member function `TimeUnit
TimeUnit::operator=(const TimeUnit&)':
debug/ns3/nstime.h:168: error: `m_data' undeclared (first use this function)
debug/ns3/nstime.h:168: error: (Each undeclared identifier is reported only
once for each function it appears in.)
debug/ns3/nstime.h: At global scope:
debug/ns3/nstime.h:172: error: expected constructor, destructor, or type
conversion before '(' token
debug/ns3/nstime.h:172: error: expected `;' before '(' token
debug/ns3/nstime.h:177: error: expected constructor, destructor, or type
conversion before "const"
debug/ns3/nstime.h:177: error: expected `;' before "const"
debug/ns3/nstime.h:183: error: expected constructor, destructor, or type
conversion before '*' token
debug/ns3/nstime.h:183: error: expected `;' before '*' token
debug/ns3/nstime.h: In member function `bool TimeUnit::IsZero() const':
debug/ns3/nstime.h:192: error: `m_data' undeclared (first use this function)
debug/ns3/nstime.h:192: error: `HighPrecision' has not been declared
debug/ns3/nstime.h:192: error: there are no arguments to `Zero' that depend on
a template parameter, so a declaration of `Zero' must be available
debug/ns3/nstime.h:192: error: (if you use `-fpermissive', G++ will accept your
code, but allowing the use of an undeclared name is deprecated)
debug/ns3/nstime.h: In member function `bool TimeUnit::IsNegative() const':
debug/ns3/nstime.h:198: error: `m_data' undeclared (first use this function)
debug/ns3/nstime.h:198: error: `HighPrecision' has not been declared
debug/ns3/nstime.h:198: error: there are no arguments to `Zero' that depend on
a template parameter, so a declaration of `Zero' must be available
debug/ns3/nstime.h: In member function `bool TimeUnit::IsPositive() const':
debug/ns3/nstime.h:204: error: `m_data' undeclared (first use this function)
debug/ns3/nstime.h:204: error: `HighPrecision' has not been declared
debug/ns3/nstime.h:204: error: there are no arguments to `Zero' that depend on
a template parameter, so a declaration of `Zero' must be available
debug/ns3/nstime.h: In member function `bool TimeUnit::IsStrictlyNegative()
const':
debug/ns3/nstime.h:210: error: `m_data' undeclared (first use this function)
debug/ns3/nstime.h:210: error: `HighPrecision' has not been declared
debug/ns3/nstime.h:210: error: there are no arguments to `Zero' that depend on
a template parameter, so a declaration of `Zero' must be available
debug/ns3/nstime.h: In member function `bool TimeUnit::IsStrictlyPositive()
const':
debug/ns3/nstime.h:216: error: `m_data' undeclared (first use this function)
debug/ns3/nstime.h:216: error: `HighPrecision' has not been declared
debug/ns3/nstime.h:216: error: there are no arguments to `Zero' that depend on
a template parameter, so a declaration of `Zero' must be available
debug/ns3/nstime.h: In function `TimeUnit operator+(const TimeUnit&,
const TimeUnit&)':
debug/ns3/nstime.h:258: error: `HighPrecision' undeclared (first use this
function)
debug/ns3/nstime.h:258: error: expected `;' before "retval"
debug/ns3/nstime.h:259: error: `retval' undeclared (first use this function)
debug/ns3/nstime.h: In function `TimeUnit operator-(const TimeUnit&,
const TimeUnit&)':
debug/ns3/nstime.h:265: error: `HighPrecision' undeclared (first use this
function)
debug/ns3/nstime.h:265: error: expected `;' before "retval"
debug/ns3/nstime.h:266: error: `retval' undeclared (first use this function)
debug/ns3/nstime.h: In function `TimeUnit<(N1 + N2)> operator*(const
TimeUnit&, const TimeUnit&)':
debug/ns3/nstime.h:272: error: `HighPrecision' undeclared (first use this
function)
debug/ns3/nstime.h:272: error: expected `;' before "retval"
debug/ns3/nstime.h:273: error: `retval' undeclared (first use this function)
debug/ns3/nstime.h: In function `TimeUnit<(N1 - N2)> operator/(const
TimeUnit&, const TimeUnit&)':
debug/ns3/nstime.h:283: error: `HighPrecision' undeclared (first use this
function)
debug/ns3/nstime.h:283: error: expected `;' before "retval"
debug/ns3/nstime.h:284: error: `retval' undeclared (first use this function)
debug/ns3/nstime.h: In function `TimeUnit& operator+=(TimeUnit&, const
TimeUnit&)':
debug/ns3/nstime.h:289: error: `HighPrecision' undeclared (first use this
function)
debug/ns3/nstime.h:289: error: `lhsv' undeclared (first use this function)
debug/ns3/nstime.h: In function `TimeUnit& operator-=(TimeUnit&, const
TimeUnit&)':
debug/ns3/nstime.h:295: error: `HighPrecision' undeclared (first use this
function)
debug/ns3/nstime.h:295: error: `lhsv' undeclared (first use this function)
debug/ns3/nstime.h: In function `TimeUnit Max(const TimeUnit&, const
TimeUnit&)':
debug/ns3/nstime.h:322: error: `HighPrecision' undeclared (first use this
function)
debug/ns3/nstime.h:322: error: expected `;' before "a"
debug/ns3/nstime.h:323: error: expected `;' before "b"
debug/ns3/nstime.h:324: error: `a' undeclared (first use this function)
debug/ns3/nstime.h:324: error: `b' undeclared (first use this function)
debug/ns3/nstime.h:324: error: no matching function for call to `Max(, )'
debug/ns3/nstime.h: In function `TimeUnit Min(const TimeUnit&, const
TimeUnit&)':
debug/ns3/nstime.h:336: error: `HighPrecision' undeclared (first use this
function)
debug/ns3/nstime.h:336: error: expected `;' before "a"
debug/ns3/nstime.h:337: error: expected `;' before "b"
debug/ns3/nstime.h:338: error: `a' undeclared (first use this function)
debug/ns3/nstime.h:338: error: `b' undeclared (first use this function)
debug/ns3/nstime.h:338: error: no matching function for call to `Max(, )'
debug/ns3/nstime.h: At global scope:
debug/ns3/nstime.h:418: error: expected `)' before "data"
debug/ns3/nstime.h:435: error: ISO C++ forbids declaration of `HighPrecision'
with no type
debug/ns3/nstime.h:435: error: expected `;' before "const"
debug/ns3/nstime.h:438: error: expected `;' before "HighPrecision"
debug/ns3/nstime.h:438: error: ISO C++ forbids declaration of `HighPrecision'
with no type
debug/ns3/nstime.h:438: error: expected `;' before '*' token
debug/ns3/nstime.h:442: error: expected `;' before "static"
debug/ns3/nstime.h:446: error: `HighPrecision' does not name a type
debug/ns3/nstime.h: In constructor `TimeUnit<1>::TimeUnit()':
debug/ns3/nstime.h:410: error: class `TimeUnit<1>' does not have any field
named `m_data'
debug/ns3/nstime.h: In copy constructor `TimeUnit<1>::TimeUnit(const
TimeUnit<1>&)':
debug/ns3/nstime.h:413: error: class `TimeUnit<1>' does not have any field
named `m_data'
debug/ns3/nstime.h:413: error: 'const class TimeUnit<1>' has no member named
'm_data'
debug/ns3/nstime.h: In member function `TimeUnit<1>
TimeUnit<1>::operator=(const TimeUnit<1>&)':
debug/ns3/nstime.h:415: error: `m_data' undeclared (first use this function)
debug/ns3/nstime.h:415: error: 'const class TimeUnit<1>' has no member named
'm_data'
debug/ns3/nstime.h: In member function `bool TimeUnit<1>::IsZero() const':
debug/ns3/nstime.h:421: error: `m_data' undeclared (first use this function)
debug/ns3/nstime.h:421: error: `HighPrecision' has not been declared
debug/ns3/nstime.h:421: error: `Zero' undeclared (first use this function)
debug/ns3/nstime.h: In member function `bool TimeUnit<1>::IsNegative() const':
debug/ns3/nstime.h:424: error: `m_data' undeclared (first use this function)
debug/ns3/nstime.h:424: error: `HighPrecision' has not been declared
debug/ns3/nstime.h:424: error: `Zero' undeclared (first use this function)
debug/ns3/nstime.h: In member function `bool TimeUnit<1>::IsPositive() const':
debug/ns3/nstime.h:427: error: `m_data' undeclared (first use this function)
debug/ns3/nstime.h:427: error: `HighPrecision' has not been declared
debug/ns3/nstime.h:427: error: `Zero' undeclared (first use this function)
debug/ns3/nstime.h: In member function `bool TimeUnit<1>::IsStrictlyNegative()
const':
debug/ns3/nstime.h:430: error: `m_data' undeclared (first use this function)
debug/ns3/nstime.h:430: error: `HighPrecision' has not been declared
debug/ns3/nstime.h:430: error: `Zero' undeclared (first use this function)
debug/ns3/nstime.h: In member function `bool TimeUnit<1>::IsStrictlyPositive()
const':
debug/ns3/nstime.h:433: error: `m_data' undeclared (first use this function)
debug/ns3/nstime.h:433: error: `HighPrecision' has not been declared
debug/ns3/nstime.h:433: error: `Zero' undeclared (first use this function)
debug/ns3/nstime.h: At global scope:
debug/ns3/nstime.h:616: error: expected `)' before "data"
debug/ns3/nstime.h:633: error: ISO C++ forbids declaration of `HighPrecision'
with no type
debug/ns3/nstime.h:633: error: expected `;' before "const"
debug/ns3/nstime.h:636: error: expected `;' before "HighPrecision"
debug/ns3/nstime.h:636: error: ISO C++ forbids declaration of `HighPrecision'
with no type
debug/ns3/nstime.h:636: error: expected `;' before '*' token
debug/ns3/nstime.h:640: error: expected `;' before "private"
debug/ns3/nstime.h:641: error: `HighPrecision' does not name a type
debug/ns3/nstime.h: In constructor `TimeUnit<0>::TimeUnit()':
debug/ns3/nstime.h:608: error: class `TimeUnit<0>' does not have any field
named `m_data'
debug/ns3/nstime.h: In copy constructor `TimeUnit<0>::TimeUnit(const
TimeUnit<0>&)':
debug/ns3/nstime.h:611: error: class `TimeUnit<0>' does not have any field
named `m_data'
debug/ns3/nstime.h:611: error: 'const class TimeUnit<0>' has no member named
'm_data'
debug/ns3/nstime.h: In member function `TimeUnit<0>
TimeUnit<0>::operator=(const TimeUnit<0>&)':
debug/ns3/nstime.h:613: error: `m_data' undeclared (first use this function)
debug/ns3/nstime.h:613: error: 'const class TimeUnit<0>' has no member named
'm_data'
debug/ns3/nstime.h: In member function `bool TimeUnit<0>::IsZero() const':
debug/ns3/nstime.h:619: error: `m_data' undeclared (first use this function)
debug/ns3/nstime.h:619: error: `HighPrecision' has not been declared
debug/ns3/nstime.h:619: error: `Zero' undeclared (first use this function)
debug/ns3/nstime.h: In member function `bool TimeUnit<0>::IsNegative() const':
debug/ns3/nstime.h:622: error: `m_data' undeclared (first use this function)
debug/ns3/nstime.h:622: error: `HighPrecision' has not been declared
debug/ns3/nstime.h:622: error: `Zero' undeclared (first use this function)
debug/ns3/nstime.h: In member function `bool TimeUnit<0>::IsPositive() const':
debug/ns3/nstime.h:625: error: `m_data' undeclared (first use this function)
debug/ns3/nstime.h:625: error: `HighPrecision' has not been declared
debug/ns3/nstime.h:625: error: `Zero' undeclared (first use this function)
debug/ns3/nstime.h: In member function `bool TimeUnit<0>::IsStrictlyNegative()
const':
debug/ns3/nstime.h:628: error: `m_data' undeclared (first use this function)
debug/ns3/nstime.h:628: error: `HighPrecision' has not been declared
debug/ns3/nstime.h:628: error: `Zero' undeclared (first use this function)
debug/ns3/nstime.h: In member function `bool TimeUnit<0>::IsStrictlyPositive()
const':
debug/ns3/nstime.h:631: error: `m_data' undeclared (first use this function)
debug/ns3/nstime.h:631: error: `HighPrecision' has not been declared
debug/ns3/nstime.h:631: error: `Zero' undeclared (first use this function)
debug/ns3/nstime.h: At global scope:
debug/ns3/nstime.h:682: error: expected constructor, destructor, or type
conversion before '<' token
debug/ns3/nstime.h:682: error: expected `;' before '<' token
debug/ns3/nstime.h:682: error: expected constructor, destructor, or type
conversion before '<' token
debug/ns3/nstime.h:682: error: expected `;' before '<' token
debug/ns3/nstime.h:683: error: expected class-name before '{' token
debug/ns3/nstime.h:683: error: ISO C++ forbids declaration of `Ptr' with no
type
debug/ns3/nstime.h:683: error: `Ptr' declared as a `virtual' field
debug/ns3/nstime.h:683: error: expected `;' before '<' token
debug/ns3/nstime.h:683: error: `Ptr' has not been declared
debug/ns3/nstime.h:683: error: expected `,' or `...' before '<' token
debug/ns3/nstime.h:683: error: ISO C++ forbids declaration of `parameter' with
no type
debug/ns3/nstime.h:683: error: `Ptr' has not been declared
debug/ns3/nstime.h:683: error: expected `,' or `...' before '<' token
debug/ns3/nstime.h:683: error: ISO C++ forbids declaration of `parameter' with
no type
debug/ns3/nstime.h:684: error: expected class-name before '{' token
get this build error on open solaris 10
debug/ns3/nstime.h:684: error: expected constructor, destructor, or type
conversion before '<' token
debug/ns3/nstime.h:684: error: expected `,' or `;' before '<' token
debug/ns3/nstime.h:686: error: expected declaration before '}' token
In file included from debug/ns3/simulator.h:27,
from ../src/core/names.cc:25:
debug/ns3/nstime.h:20:1: unterminated #ifndef
In file included from ../src/core/names.cc:25:
debug/ns3/simulator.h:21:1: unterminated #ifndef
Waf: Leaving directory
`/export/home/salil/Documents/ns-allinone-3.5.1/ns-3.5.1/build'
Build failed
-> task failed (err #1):
{task: cxx names.cc -> names_1.o}
Traceback (most recent call last):
File "build.py", line 117, in ?
sys.exit(main(sys.argv))
File "build.py", line 108, in main
build_ns3(config)
File "build.py", line 56, in build_ns3
run_command(["python", "waf"])
File "/export/home/salil/Documents/ns-allinone-3.5.1/util.py", line 24, in
run_command
raise CommandError("Command %r exited with code %i" % (argv, retval))
util.CommandError: Command ['python', 'waf'] exited with code 1
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Oct 6 21:16:32 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 07 Oct 2009 00:16:32 -0400
Subject: [Ns-bugs] [Bug 424] TCP FIN notification callback needed
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=424
--- Comment #11 from Tom Henderson 2009-10-07 00:16:32 EDT ---
(In reply to comment #10)
> Created an attachment (id=610)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=610) [details]
> Correct broken close semantics/implementation
>
> Fixes several problems with TCP close semantics. Appears to fix bugs
> 326, 559, 663, and 664 also.
>
I think that the newly proposed socket API is necessary. Because it isn't
plumbed in for NSC yet, and because it is too close to code freeze, I suggest
to split this patch into two patches; one dealing with TCP internal closing
fixes (that also fixes other TCP bugs) and one dealing with the two new socket
callbacks, and keep this open and at P2, and that we resolve this in the next
month including for NSC.
One question I have concerns when NotifyNormalClose should be called. The
proposed patch calls it when the TCP receiver has received the FIN in sequence
(or plugs all remaining sequence gaps) but is not tied to whether the
application has read through to EOF. Another possible implementation would
call it only after the application has read through to EOF.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Wed Oct 7 06:12:17 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 07 Oct 2009 09:12:17 -0400
Subject: [Ns-bugs] [Bug 708] New: SendCallback does not work with NSC
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=708
Summary: SendCallback does not work with NSC
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: internet-stack
AssignedTo: ns-bugs at isi.edu
ReportedBy: alberto.blanc at gmail.com
Estimated Hours: 0.0
Trying to modify the tcp-large-transfer to used NSC I realized that the
SendCallback does not work when using NSC, in the sense that the function
registered as a callback is never called.
Looking at TcpSocketImpl I've noticed that the function NotifySend (which calls
the callback function) is called several times. While in NscTcpSocketImpl this
function is never called.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Wed Oct 7 20:12:47 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 07 Oct 2009 23:12:47 -0400
Subject: [Ns-bugs] [Bug 697] TCP "Sent" callback reports wrong count
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=697
Bug 697 depends on bug 424, which changed state.
Bug 424 Summary: TCP FIN notification callback needed
http://www.nsnam.org/bugzilla/show_bug.cgi?id=424
What |Old Value |New Value
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Wed Oct 7 20:13:03 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 07 Oct 2009 23:13:03 -0400
Subject: [Ns-bugs] [Bug 426] TCP: close does not send RST
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=426
Josh Pelkey changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jpelkey at gatech.edu
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #8 from Josh Pelkey 2009-10-07 23:13:02 EDT ---
changeset c54b36fb7317
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Wed Oct 7 20:12:46 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 07 Oct 2009 23:12:46 -0400
Subject: [Ns-bugs] [Bug 424] TCP FIN notification callback needed
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=424
Josh Pelkey changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jpelkey at gatech.edu
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #12 from Josh Pelkey 2009-10-07 23:12:46 EDT ---
changeset c54b36fb7317
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Wed Oct 7 20:13:53 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 07 Oct 2009 23:13:53 -0400
Subject: [Ns-bugs] [Bug 664] memory fault/dangling pointer problems in
tcp-socket-impl.cc, with suggested fixes
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=664
Josh Pelkey changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jpelkey at gatech.edu
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Josh Pelkey 2009-10-07 23:13:53 EDT ---
changeset c54b36fb7317
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Wed Oct 7 20:14:12 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 07 Oct 2009 23:14:12 -0400
Subject: [Ns-bugs] [Bug 697] TCP "Sent" callback reports wrong count
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=697
Josh Pelkey changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jpelkey at gatech.edu
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Josh Pelkey 2009-10-07 23:14:12 EDT ---
changeset c54b36fb7317
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 8 11:25:13 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 08 Oct 2009 14:25:13 -0400
Subject: [Ns-bugs] [Bug 709] New: Crazy Idea -- Default trace sink
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=709
Summary: Crazy Idea -- Default trace sink
Product: ns-3
Version: pre-release
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P5
Component: simulation core
AssignedTo: ns-bugs at isi.edu
ReportedBy: craigdo at ee.washington.edu
Estimated Hours: 0.0
It occurred to me that it might be possible to specify a kind of default trace
sink that appends traced text to the end of a file.
If a bound callback is created that takes a file name and a format string to
bind, it may be possible to construct a trace sink that just writes trace
results to the specified file using the format string without actually having
to code a trace sink (the actual trace sink could be made from a template in
the core).
As a wild guess on a possible syntax:
Config::ConnectDefault<2> ("/NodeList ... CongestionWindow", "my-trace-file",
"CongestionWindow changed from %d to %d")
This would try to convince a default trace sink taking four arguments (two
provided by the source + two bound) to take template argument a1 and sprintf it
using %d, and take argument a2 and sprintf it using %d. This woud result in a
string that looked like, "CongestionWindow changed from 1 to 2" which would be
appended to the file "my-trace-file"
Haven't worked it through, multithreading may require locks, but I wanted to
write it down since it sounds like it would be incredibly convenient to lots of
users.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 8 23:21:09 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 09 Oct 2009 02:21:09 -0400
Subject: [Ns-bugs] [Bug 710] New: simple-wifi-frame-aggregation fails
valgrind
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=710
Summary: simple-wifi-frame-aggregation fails valgrind
Product: ns-3
Version: pre-release
Platform: All
OS/Version: All
Status: NEW
Severity: blocker
Priority: P1
Component: sample programs
AssignedTo: ns-bugs at isi.edu
ReportedBy: craigdo at ee.washington.edu
Estimated Hours: 0.0
This is a problem with uninitialized bytes being written to a pcap file. I
suspect it may be in packet aggregation.
happens on ns-regression: configured for debug; gcc version 4.2.4 (Ubuntu
4.2.4-1ubuntu4); Linux version 2.6.24-19-server
reproduce with:
./waf --run simple-wifi-frame-aggregation --valgrind
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 8 23:22:53 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 09 Oct 2009 02:22:53 -0400
Subject: [Ns-bugs] [Bug 711] New: example mesh/mesh fails valgrind
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
Summary: example mesh/mesh fails valgrind
Product: ns-3
Version: pre-release
Platform: All
OS/Version: All
Status: NEW
Severity: blocker
Priority: P1
Component: sample programs
AssignedTo: ns-bugs at isi.edu
ReportedBy: craigdo at ee.washington.edu
Estimated Hours: 0.0
happens on ns-regression: configured for debug; gcc version 4.2.4 (Ubuntu
4.2.4-1ubuntu4); Linux version 2.6.24-19-server
reproduce with:
./waf --run mesh --valgrind
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 8 23:28:18 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 09 Oct 2009 02:28:18 -0400
Subject: [Ns-bugs] [Bug 712] New: TestSute ns3-tcp-cwnd crashes under
valgrind
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=712
Summary: TestSute ns3-tcp-cwnd crashes under valgrind
Product: ns-3
Version: pre-release
Platform: All
OS/Version: All
Status: NEW
Severity: blocker
Priority: P1
Component: regression
AssignedTo: ns-bugs at isi.edu
ReportedBy: craigdo at ee.washington.edu
Estimated Hours: 0.0
This seems to be an illegal instruction problem in NSC TCP. Sounds familiar.
happens on ns-regression: configured for debug; gcc version 4.2.4 (Ubuntu
4.2.4-1ubuntu4); Linux version 2.6.24-19-server
reproduce with:
./waf --run "test-runner --suite=ns3-tcp-cwnd --basedir=`pwd`" --valgrind
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 8 23:30:12 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 09 Oct 2009 02:30:12 -0400
Subject: [Ns-bugs] [Bug 713] New: TestSute ns3-tcp-interoperability crashes
under valgrind
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=713
Summary: TestSute ns3-tcp-interoperability crashes under valgrind
Product: ns-3
Version: pre-release
Platform: All
OS/Version: All
Status: NEW
Severity: blocker
Priority: P1
Component: regression
AssignedTo: ns-bugs at isi.edu
ReportedBy: craigdo at ee.washington.edu
Estimated Hours: 0.0
This seems to be an illegal instruction problem in NSC TCP. Sounds familiar.
happens on ns-regression: configured for debug; gcc version 4.2.4 (Ubuntu
4.2.4-1ubuntu4); Linux version 2.6.24-19-server
reproduce with:
./waf --run "test-runner --suite=ns3-tcp-interoperability --basedir=`pwd`"
--valgrind
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 8 23:43:49 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 09 Oct 2009 02:43:49 -0400
Subject: [Ns-bugs] [Bug 714] New: TestSute ns3-tcp-cwnd fails
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=714
Summary: TestSute ns3-tcp-cwnd fails
Product: ns-3
Version: pre-release
Platform: All
OS/Version: All
Status: NEW
Severity: blocker
Priority: P1
Component: regression
AssignedTo: ns-bugs at isi.edu
ReportedBy: craigdo at ee.washington.edu
Estimated Hours: 0.0
This is an artifact of the recent TCP patch. Unknown whether or not this is a
real failure.
happens on ns-regression: configured for debug; gcc version 4.2.4 (Ubuntu
4.2.4-1ubuntu4); Linux version 2.6.24-19-server
reproduce with:
./waf --run "test-runner --suite=ns3-tcp-cwnd --basedir=`pwd`"
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 9 02:53:30 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 09 Oct 2009 05:53:30 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
Andrey Mazo changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mazo at iitp.ru
--- Comment #1 from Andrey Mazo 2009-10-09 05:53:30 EDT ---
(In reply to comment #0)
> happens on ns-regression: configured for debug; gcc version 4.2.4 (Ubuntu
> 4.2.4-1ubuntu4); Linux version 2.6.24-19-server
>
> reproduce with:
>
> ./waf --run mesh --valgrind
A brief investigation showed, that valgrind is happy on x86 machine
1) gcc-4.2.4 and gcc-4.3.2
2) valgrind-3.3.1 and valgrind-3.4.1
It seems, that the problem is x86-64 specific.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 9 09:05:06 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 09 Oct 2009 12:05:06 -0400
Subject: [Ns-bugs] [Bug 714] TestSute ns3-tcp-cwnd fails
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=714
Josh Pelkey changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jpelkey at gatech.edu
--- Comment #1 from Josh Pelkey 2009-10-09 12:05:06 EDT ---
I looked at this a little bit a few days ago after I pushed the TCP patches.
To just relay some information for future reference to this bug, I compared the
pcap files from the old (passing) testcase and the new (failing) test case. I
didn't look at every single packet in detail, but I believe they were identical
(same number of packets, same time events, etc).
The testcase is failing because the total number of events is less than the
expected 21. It is instead 20. So the last event that the testcase refers to
(the "slamming shut" of the tcp cwnd) is not occuring. I am unsure of whether
or not this should actually happen.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 9 10:50:45 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 09 Oct 2009 13:50:45 -0400
Subject: [Ns-bugs] [Bug 710] simple-wifi-frame-aggregation fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=710
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 9 12:05:16 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 09 Oct 2009 15:05:16 -0400
Subject: [Ns-bugs] [Bug 712] TestSute ns3-tcp-cwnd crashes under valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=712
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 9 12:05:32 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 09 Oct 2009 15:05:32 -0400
Subject: [Ns-bugs] [Bug 713] TestSute ns3-tcp-interoperability crashes under
valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=713
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Mon Oct 12 02:15:17 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 12 Oct 2009 05:15:17 -0400
Subject: [Ns-bugs] [Bug 715] New: let ./test.py not to store traces in
/tmp/unchecked-traces in multiuser environment
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=715
Summary: let ./test.py not to store traces in /tmp/unchecked-
traces in multiuser environment
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P4
Component: build system
AssignedTo: ns-bugs at isi.edu
ReportedBy: mazo at iitp.ru
Estimated Hours: 0.0
Created an attachment (id=623)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=623)
proposed change
Say, 2 users are running ./test.py simultaneously.
Both of them are trying to write their tests to /tmp/unchecked-traces, causing
random tests crashes.
This is usually not an issue for desktop runs, but really a problem for servers
with many users.
So, I suggest to move TMP_TRACES_DIR and TMP_OUTPUT_DIR to the ns-3 build
directory (like "build/optimized/tmp").
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Mon Oct 12 14:01:17 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 12 Oct 2009 17:01:17 -0400
Subject: [Ns-bugs] [Bug 715] let ./test.py not to store traces in
/tmp/unchecked-traces in multiuser environment
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=715
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |craigdo at ee.washington.edu
Severity|normal |blocker
Priority|P4 |P1
--- Comment #1 from Craig Dowell 2009-10-12 17:01:17 EDT ---
The number of temporary files was getting annoyingly large, and it was harder
than expected to find output files for debugging, so I reworked this area
completely.
test.py now stores its temporary files "locally" an not in /tmp. It creates a
"testpy-output" directory and saves temporary files under the directory
"testpy-output" with a timestamp for a name, like,
2009-10-12-20-54-26-CUT/
This is year, month, day, hour, minute, second Coordinated Universal Time.
Normally, test.py creates dozens of little temporary files and trace files as
it runs. If you don't select the --retain option, these temporary files are
removed by deleting the directory above.
If you "./test.py --retain" then test.py will not delete the temporary files.
e.g.
./test.py -r
or
./test.py --retain
You can then wander around in the (currently) 373 temporary files generated
during a complete test run and try and figure out what went wrong.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Mon Oct 12 14:03:01 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 12 Oct 2009 17:03:01 -0400
Subject: [Ns-bugs] [Bug 715] let ./test.py not to store traces in
/tmp/unchecked-traces in multiuser environment
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=715
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Craig Dowell 2009-10-12 17:03:01 EDT ---
Fixed changeset 00d7fe69d024
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Mon Oct 12 23:35:34 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 13 Oct 2009 02:35:34 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
--- Comment #2 from Craig Dowell 2009-10-13 02:35:34 EDT ---
valgrind invalid reads are apparently due to valgrind having a problem with a
particular flavor of anonymous temporary via iterator:
It doesn't like
tag.SetAddress (*i);
but does like
Mac48Address address = *i;
tag.SetAddress (address);
Most memory leaks due to the old problem of trying to use stl::container.erase
to release Ptr without explicit zero of the Ptr.
Still another leak left.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Oct 13 00:20:41 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 13 Oct 2009 03:20:41 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
--- Comment #3 from Craig Dowell 2009-10-13 03:20:41 EDT ---
The last problem is the following if someone wants to take a crack at it:
==3120==
==3120== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
==3120== malloc/free: in use at exit: 60,468 bytes in 701 blocks.
==3120== malloc/free: 1,909,817 allocs, 1,909,116 frees, 110,667,282 bytes
allocated.
==3120== For counts of detected errors, rerun with: -v
==3120== searching for pointers to 701 not-freed blocks.
==3120== checked 1,112,200 bytes.
==3120==
==3120== 60,468 (56 direct, 60,412 indirect) bytes in 1 blocks are definitely
lost in loss record 8 of 75
==3120== at 0x4C23809: operator new(unsigned long) (vg_replace_malloc.c:230)
==3120== by 0x58D7ECE: ns3::EventImpl* ns3::MakeEvent, ns3::Ptr), ns3::YansWifiPhy*, ns3::Ptr,
ns3::Ptr >(void (ns3::YansWifiPh
y::*)(ns3::Ptr, ns3::Ptr),
ns3::YansWifiPhy*, ns3::Ptr, ns3::Ptr) (make-event.h:145)
==3120== by 0x58D7FCC: ns3::EventId ns3::Simulator::Schedule, ns3::Ptr), ns3::YansWifiPhy*, ns3::Ptr,
ns3::Ptr >(ns3::TimeUnit<
1> const&, void (ns3::YansWifiPhy::*)(ns3::Ptr,
ns3::Ptr), ns3::YansWifiPhy*, ns3::
Ptr, ns3::Ptr) (simulator.h:661)
==3120== by 0x58D1AE2:
ns3::YansWifiPhy::StartReceivePacket(ns3::Ptr, double,
ns3::WifiMode, ns3::WifiPreamble)
(yans-wifi-phy.cc:441)
==3120== by 0x58D9197: ns3::YansWifiChannel::Receive(unsigned,
ns3::Ptr, double, ns3::WifiMode, ns3::WifiPreambl
e) const (yans-wifi-channel.cc:104)
==3120== by 0x58D9282:
_ZZN3ns39MakeEventIMNS_15YansWifiChannelEKFvjNS_3PtrINS_6PacketEEEdNS_8WifiModeENS_12WifiPreambleEEPKS
1_jS4_dS5_S6_EEPNS_9EventImplET_T0_T1_T2_T3_T4_T5_EN16EventMemberImpl56NotifyEv
(make-event.h:230)
==3120== by 0x552ADAE: ns3::EventImpl::Invoke() (event-impl.cc:39)
==3120== by 0x5546592: ns3::DefaultSimulatorImpl::ProcessOneEvent()
(default-simulator-impl.cc:113)
==3120== by 0x55465DA: ns3::DefaultSimulatorImpl::Run()
(default-simulator-impl.cc:143)
==3120== by 0x5532DA6: ns3::Simulator::Run() (simulator.cc:160)
==3120== by 0x40DE49: MeshTest::Run() (mesh.cc:221)
==3120== by 0x40F045: main (mesh.cc:250)
==3120==
==3120== LEAK SUMMARY:
==3120== definitely lost: 56 bytes in 1 blocks.
==3120== indirectly lost: 60,412 bytes in 700 blocks.
==3120== possibly lost: 0 bytes in 0 blocks.
==3120== still reachable: 0 bytes in 0 blocks.
==3120== suppressed: 0 bytes in 0 blocks.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Oct 13 01:21:03 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 13 Oct 2009 04:21:03 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
--- Comment #4 from Andrey Mazo 2009-10-13 04:21:03 EDT ---
(In reply to comment #2)
> Most memory leaks due to the old problem of trying to use stl::container.erase
> to release Ptr without explicit zero of the Ptr.
Are there any FAQ entry about this old problem?
It's not an obvious thing, because erase() must call Ptr::~Ptr(), which in turn
must call Unref() and then free the allocated memory.
I don't yet understand, why it is required to call Unref() manually by setting
the Ptr to zero.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Oct 13 06:05:50 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 13 Oct 2009 09:05:50 -0400
Subject: [Ns-bugs] [Bug 717] New: Wrong slrc calculation at
WifiRemoteStationManager when QoS is working
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=717
Summary: Wrong slrc calculation at WifiRemoteStationManager when
QoS is working
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: critical
Priority: P3
Component: wifi
AssignedTo: ns-bugs at isi.edu
ReportedBy: andreev at iitp.ru
Estimated Hours: 0.0
Suppose the following situation:
We have two stations A and B and we have two queues at each stations and
packets to be sent in both queues at station A (all the packets are addressed
to the station B). The second queue (with lower priority) has started to
transmit a packet, but this packet has crashed (due to PER for example). After
it DcaTxop will be notifyed about transmission failure and m_slrc in
WifiRemoteStation shall be incremented. After this event, the first queue (with
higher priority) has accessed the medium and started to transmit its frame.
After successfull transmission m_slrc counter shall be set to 0, and previously
crashed frame shall be transmitted with wrong slrc counter. Now suppose that
station A and B can not communicate -- so, the packets from AC_BE queue shall
be retried too many times when packets from AC_VO shall be dropped due to retry
counter.
Proposed solution - is to add a map of rather
than keeping retry counter only in WifiRemoteStationManager (but I do not know
how will work rate control algorithms), like described in 9.9.1.6 of
802.11-2007, - short and long retry counters shall be supported for each AC
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Oct 13 10:22:36 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 13 Oct 2009 13:22:36 -0400
Subject: [Ns-bugs] [Bug 718] New: Syntax error in test.py
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=718
Summary: Syntax error in test.py
Product: ns-3
Version: pre-release
Platform: All
OS/Version: All
Status: NEW
Severity: blocker
Priority: P1
Component: regression
AssignedTo: ns-bugs at isi.edu
ReportedBy: craigdo at ee.washington.edu
Estimated Hours: 0.0
Stray () in class
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Oct 13 10:22:44 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 13 Oct 2009 13:22:44 -0400
Subject: [Ns-bugs] [Bug 718] Syntax error in test.py
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=718
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Oct 13 12:10:46 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 13 Oct 2009 15:10:46 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
--- Comment #5 from Andrey Mazo 2009-10-13 15:10:46 EDT ---
(In reply to comment #3)
Well, I'm having completely different valgrind report on i686:
==31146==
==31146== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 1)
==31146== malloc/free: in use at exit: 39,444 bytes in 701 blocks.
==31146== malloc/free: 1,892,925 allocs, 1,892,224 frees, 77,338,893 bytes
allocated.
==31146== For counts of detected errors, rerun with: -v
==31146== searching for pointers to 701 not-freed blocks.
==31146== checked 389,836 bytes.
==31146==
==31146== 39,444 (60 direct, 39,384 indirect) bytes in 1 blocks are definitely
lost in loss record 9 of 75
==31146== at 0x40256F3: operator new(unsigned int) (in
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==31146== by 0x833C902: ns3::Ptr ns3::CreateObject()
(object.h:484)
==31146== by 0x8630953: ns3::NodeContainer::Create(unsigned int)
(node-container.cc:96)
==31146== by 0x804F568: MeshTest::CreateNodes() (mesh.cc:150)
==31146== by 0x805200A: MeshTest::Run() (mesh.cc:216)
==31146== by 0x80539E5: main (mesh.cc:250)
==31146==
==31146== LEAK SUMMARY:
==31146== definitely lost: 60 bytes in 1 blocks.
==31146== indirectly lost: 39,384 bytes in 700 blocks.
==31146== possibly lost: 0 bytes in 0 blocks.
==31146== still reachable: 0 bytes in 0 blocks.
==31146== suppressed: 0 bytes in 0 blocks.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Wed Oct 14 02:18:08 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 14 Oct 2009 05:18:08 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
--- Comment #6 from Andrey Mazo 2009-10-14 05:18:08 EDT ---
Created an attachment (id=624)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=624)
fix several possible leaks
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Wed Oct 14 04:01:37 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 14 Oct 2009 07:01:37 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
Andrey Mazo changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #624 is|0 |1
obsolete| |
--- Comment #7 from Andrey Mazo 2009-10-14 07:01:37 EDT ---
Created an attachment (id=625)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=625)
fix some more leaks
This patch makes amd64 valgrind output similar to i686.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Wed Oct 14 10:01:24 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 14 Oct 2009 13:01:24 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
Andrey Mazo changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #625 is|0 |1
obsolete| |
--- Comment #8 from Andrey Mazo 2009-10-14 13:01:24 EDT ---
Created an attachment (id=626)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=626)
and even more fixes
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Wed Oct 14 12:01:26 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 14 Oct 2009 15:01:26 -0400
Subject: [Ns-bugs] [Bug 720] New: TapBridge creation fails from a script
outside the ns3 tree
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=720
Summary: TapBridge creation fails from a script outside the ns3
tree
Product: ns-3
Version: ns-3.5.1
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: devices
AssignedTo: ns-bugs at isi.edu
ReportedBy: vkawadia at bbn.com
Estimated Hours: 0.0
A script running from outside the ns tree that attempts to create a TapBridge
throws the following error:
Parent process
Child process
TapBridge::FindCreator(): Couldn't find creator
TapBridge::CreateTap(): socket creator exited abnormally
Segmentation fault
The cause seems to be that when trying to execl "tap-creator", we search only
in the build tree. This is in the FindCreator function in
devices/tap-bridge.cc. Paths to search are in-fact hard-coded, which seems
unclean. Example:
locations.push_back ("./build/optimized/src/devices/tap-bridge/");
The following change enables searching for tap-creator in $PATH. It uses execlp
instead of execl and does not call FindCreator. This enables a script using
TapBridge to work from anywhere if tap-creator is in the path. Inside the ns3
tree, one should probably have waf --run modify paths appropriately.
--- tap-bridge-orig.cc 2009-10-14 14:30:38.000000000 -0400
+++ tap-bridge.cc 2009-10-14 14:30:54.000000000 -0400
@@ -432,8 +432,8 @@
//
// Execute the socket creation process image.
//
- status = ::execl (FindCreator ("tap-creator").c_str (),
- FindCreator ("tap-creator").c_str (), // argv[0]
(filename)
+ status = ::execlp ("tap-creator",
+ "tap-creator", // argv[0]
(filename)
ossDeviceName.str ().c_str (), // argv[1]
(-d)
ossGateway.str ().c_str (), // argv[2]
(-g)
ossIp.str ().c_str (), // argv[3]
(-i)
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Wed Oct 14 13:50:30 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 14 Oct 2009 16:50:30 -0400
Subject: [Ns-bugs] [Bug 720] TapBridge creation fails from a script outside
the ns3 tree
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=720
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |craigdo at ee.washington.edu
--- Comment #1 from Craig Dowell 2009-10-14 16:50:29 EDT ---
The reason it works that way is to support multiple builds of different
versions. For example, I currently have 24 different builds of different
versions of ns-3 on my primary machine.
This wouldn't work very well if the code looked into $PATH for the creator.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Wed Oct 14 16:39:40 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 14 Oct 2009 19:39:40 -0400
Subject: [Ns-bugs] [Bug 721] New: Explicit releases of Ptr<> throughout
codebase
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=721
Summary: Explicit releases of Ptr<> throughout codebase
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: minor
Priority: P5
Component: simulation core
AssignedTo: ns-bugs at isi.edu
ReportedBy: craigdo at ee.washington.edu
Estimated Hours: 0.0
It used to be the case that when stl containers were used with ns-3::Ptr<>, an
explicit release of the Ptr was required (e.g, *i = 0) to avoid memory leaks.
This behavior has changed and I can no longer verify any leaks when this these
releases are removed.
There are vestigial remains of this problem scattered throught the codebase
which should be removed since they now reflect unnecessary complexity that is
being cut and pasted into new code.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Wed Oct 14 16:44:22 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Wed, 14 Oct 2009 19:44:22 -0400
Subject: [Ns-bugs] [Bug 722] New: tap-wifi-dumbbell.cc busted
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=722
Summary: tap-wifi-dumbbell.cc busted
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P3
Component: devices
AssignedTo: ns-bugs at isi.edu
ReportedBy: craigdo at ee.washington.edu
Estimated Hours: 0.0
The non-trivial operating modes demonstrated by tap-wifi-dumbell.cc have
stopped working.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 15 02:07:11 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 15 Oct 2009 05:07:11 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
Andrey Mazo changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #626 is|0 |1
obsolete| |
--- Comment #9 from Andrey Mazo 2009-10-15 05:07:11 EDT ---
Created an attachment (id=627)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=627)
valgrind happy!!
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 15 02:51:40 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 15 Oct 2009 05:51:40 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
--- Comment #10 from Andrey Mazo 2009-10-15 05:51:40 EDT ---
(In reply to comment #9)
> Created an attachment (id=627)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=627) [details]
> valgrind happy!!
I'll now split this patch into several patches and remove some redundancy.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 15 02:54:11 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 15 Oct 2009 05:54:11 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
--- Comment #11 from Andrey Mazo 2009-10-15 05:54:11 EDT ---
Created an attachment (id=628)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=628)
add NS_LOG_FUNCTION to constructors/destructors/DoDisposes
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 15 03:18:49 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 15 Oct 2009 06:18:49 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
--- Comment #12 from Andrey Mazo 2009-10-15 06:18:49 EDT ---
Created an attachment (id=629)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=629)
Fix the bug itself
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 15 03:33:30 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 15 Oct 2009 06:33:30 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
--- Comment #13 from Andrey Mazo 2009-10-15 06:33:30 EDT ---
Created an attachment (id=630)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=630)
remove some redundant cleanups, includes, etc
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 15 03:43:50 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 15 Oct 2009 06:43:50 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
--- Comment #14 from Andrey Mazo 2009-10-15 06:43:50 EDT ---
(In reply to comment #13)
> Created an attachment (id=630)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=630) [details]
> remove some redundant cleanups, includes, etc
Split complete.
Apply in posted order.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 15 08:31:50 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 15 Oct 2009 11:31:50 -0400
Subject: [Ns-bugs] [Bug 720] TapBridge creation fails from a script outside
the ns3 tree
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=720
--- Comment #2 from Vikas Kawadia 2009-10-15 11:31:50 EDT ---
I see how it makes testing convenient for you.
But I am using ns3 in a fairly normal way, i.e., importing it into my python
package which lives in another repository. It is not practical to have the
entire ns3 tree in there. I see no way to make my setup work without patching
ns3 in some way.
Perhaps, there is a way make both of us happy. Here are some suggestions:
1) Make tap-creator a separate program living in ns3 top-level and built
separately. Then have ns3's 'waf configure' find it and pass it to the current
build. After all, tap-creator is really a convenience utility, mostly unrelated
to ns3.
2) Alternatively, waf --run (and/or --pyrun) could find the tap-creator for the
version being built and put it in the path.
ns3 is a great project, a pleasant surprise for an erstwhile ns2 user like
myself. Thanks for doing it so well. I would love to see it packaged for the
major linux and bsd distributions in the near future. And hardcoded things like
this do get in the way. In fact, the whole "running everything through waf"
model bothers me a bit.
-vikas
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 15 11:14:23 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 15 Oct 2009 14:14:23 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 15 12:06:24 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 15 Oct 2009 15:06:24 -0400
Subject: [Ns-bugs] [Bug 714] TestSute ns3-tcp-cwnd fails
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=714
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Thu Oct 15 13:16:29 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Thu, 15 Oct 2009 16:16:29 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
--- Comment #15 from Andrey Mazo 2009-10-15 16:16:29 EDT ---
Changeset 21a4f34518ff
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 16 03:29:44 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 16 Oct 2009 06:29:44 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
--- Comment #16 from Andrey Mazo 2009-10-16 06:29:44 EDT ---
(In reply to comment #15)
> Changeset 21a4f34518ff
Well, the more I think about this fix, the more I believe, that it's a
workaround.
1) someone may not use mesh-helper and thus introduce the same circular
references again
2) someone may create circular references through callbacks involving three or
more objects, which will be much harder to detect
3) callback may be invoked, when the object it references is already destroyed,
thus leading to a memory corruption or a segfault (though I still cannot
imagine such a situation)
I think, a better solution is to assign NullCallbacks to all callbacks in
DoDispose ()'s.
I'm going to attach a patch reverting this changeset and applying the correct
fix.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 16 03:36:00 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 16 Oct 2009 06:36:00 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
Andrey Mazo changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #627 is|0 |1
obsolete| |
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 16 03:47:32 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 16 Oct 2009 06:47:32 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
--- Comment #17 from Andrey Mazo 2009-10-16 06:47:32 EDT ---
Created an attachment (id=631)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=631)
more correct fix for the bug
currently can't test it on ns-regressions
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 16 08:29:37 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 16 Oct 2009 11:29:37 -0400
Subject: [Ns-bugs] [Bug 723] New: Python bindings not fully up to date
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=723
Summary: Python bindings not fully up to date
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: python bindings
AssignedTo: ns-bugs at isi.edu
ReportedBy: gjcarneiro at gmail.com
Estimated Hours: 0.0
gjc at dark-tower:flowmon$ python wifi-olsr-flowmon.py
Traceback (most recent call last):
File "wifi-olsr-flowmon.py", line 170, in
sys.exit(main(sys.argv))
File "wifi-olsr-flowmon.py", line 50, in main
list_routing = ns3.Ipv4ListRoutingHelper()
TypeError: class 'Ipv4ListRoutingHelper' cannot be constructed (have pure
virtual methods but no helper class)
This could (perhaps) be due to need to rescan Python bindings.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 16 09:05:25 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 16 Oct 2009 12:05:25 -0400
Subject: [Ns-bugs] [Bug 723] Python bindings not fully up to date
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=723
--- Comment #1 from Gustavo J. A. M. Carneiro 2009-10-16 12:05:25 EDT ---
Hmm.. apparently rescanning doesn't solve it. I have to look into this with
more detail...
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 16 10:59:12 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 16 Oct 2009 13:59:12 -0400
Subject: [Ns-bugs] [Bug 723] Python bindings not fully up to date
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=723
--- Comment #2 from Gustavo J. A. M. Carneiro 2009-10-16 13:59:12 EDT ---
Created an attachment (id=632)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=632)
patch
It was a trivial bug in pybindgen. Pybindgen upgrade required.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 16 11:03:22 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 16 Oct 2009 14:03:22 -0400
Subject: [Ns-bugs] [Bug 723] Python bindings not fully up to date
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=723
Craig Dowell changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |craigdo at ee.washington.edu
Severity|normal |blocker
Priority|P5 |P1
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 16 18:18:47 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Fri, 16 Oct 2009 21:18:47 -0400
Subject: [Ns-bugs] [Bug 722] tap-wifi-dumbbell.cc busted
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=722
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tomh at tomh.org
--- Comment #1 from Tom Henderson 2009-10-16 21:18:46 EDT ---
I just tried to test this on ns-test and found the following:
the example cases 1,2,3 and 5 in examples/tap/tap-wifi-dumbbell.cc worked for
me in repeated trials. Previously, when I reported this bug verbally, I was on
a different machine and could not get any of the modes to work, but I suspect
now that the other machine did not have tap framework working properly.
case 4 (doesn't work on ns-test) is the following:
// 4) Try to run this in UseLocal mode. This allows you to provide an existing
// pre-configured tap device to the simulation. The IP address and MAC
// address in this mode do not have to match those of the ns-3 device.
//
// sudo tunctl -t mytap
// sudo ifconfig mytap hw ether 08:00:2e:00:00:01
// sudo ifconfig mytap 10.1.1.1 netmask 255.255.255.0 up
// ./waf --run "tap-wifi-dumbbell --mode=UseLocal --tapName=mytap"&
// ping 10.1.1.3
In this mode, the TapBridge discovers, during run-time, the overlying MAC
address of the tap device, and sets the underlying ns-3 NetDevice to have the
same mac address.
What is going on in this example is that the simulation starts, and a little
while later, the TapBridge gets a packet and sets the underlying wifi address.
However, the client has already associated to the ap with a previous mac
address (the one that ns-3 initially assigned). This generates the following
drop message in NqstaWifiMac:
"Received data frame not from the BSS we are associated with: ignore
08:00:2e:00:00:01"
Recall that we introduced this mode of "UseLocal" to work around some issues
with hooking TapBridge to other virtual machine frameworks. This doesn't seem
to be easy to make work with infrastructure-mode-- am not sure about whether it
still works with ad hoc mode.
For the release, I suggest that we remove use case 4) from the example
(actually, leave a comment in the example that UseLocal presently doesn't work
with this example because the underlying devices associate with the original
mac addresses) and keep open a bug named such as "TapBridge UseLocal mode not
robust enough" and deal with it post-release.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Fri Oct 16 21:29:29 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Sat, 17 Oct 2009 00:29:29 -0400
Subject: [Ns-bugs] [Bug 711] example mesh/mesh fails valgrind
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=711
--- Comment #18 from Andrey Mazo 2009-10-17 00:29:29 EDT ---
(In reply to comment #17)
> Created an attachment (id=631)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=631) [details]
> more correct fix for the bug
>
> currently can't test it on ns-regressions
valgrind on ns-regressions also seems to be silent.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Mon Oct 19 07:03:10 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 19 Oct 2009 10:03:10 -0400
Subject: [Ns-bugs] [Bug 725] New: L-2 fragmentation and RTS cannot be used
at the same time
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=725
Summary: L-2 fragmentation and RTS cannot be used at the same
time
Product: ns-3
Version: ns-3-dev
Platform: PC
URL: http://pastebin.com/m738f9349
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P4
Component: wifi
AssignedTo: ns-bugs at isi.edu
ReportedBy: c.facchini at gmail.com
Estimated Hours: 0.0
Created an attachment (id=633)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=633)
Frag threshold set at 800, RTS threshold set at 100. Still RTS handshake is not
triggered.
It seems that MAC-layer fragmentation and RTS handshake cannot be used at the
same time.
In particular, when turning on both mechanisms only fragmentation gets
actually turned on.
According to the standard, it should be possible to use both mechanisms
jointly.
To reproduce this bug, just set FragmentationThreshold and RtsCtsThreshold
accordingly.
As an example, they could be set this way:
Config::SetDefault ("ns3::WifiRemoteStationManager::FragmentationThreshold",
StringValue ("800"));
Config::SetDefault ("ns3::WifiRemoteStationManager::RtsCtsThreshold",
StringValue ("100"));
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Mon Oct 19 09:13:51 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Mon, 19 Oct 2009 12:13:51 -0400
Subject: [Ns-bugs] [Bug 725] L-2 fragmentation and RTS cannot be used at the
same time
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=725
--- Comment #1 from Christian 2009-10-19 12:13:51 EDT ---
Created an attachment (id=634)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=634)
(Very simple) patch proposed to overcome this issue
As correctly pointed out here:
http://groups.google.com/group/ns-3-users/browse_thread/thread/b96cfbe60458bbf1
the problem seems due to the instruction params.DisableRts() in function
DcaTxop::NotifyAccessGranted (in src/devices/wifi/dca-txop.cc).
The patched code simply calls params.EnableRts() after checking RTS is actually
needed.
As a result, the RTS handshake is called only for the first fragment and the
duration field is properly set to cover up to the first ACK (as stated in the
standard).
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Oct 20 02:46:39 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 20 Oct 2009 05:46:39 -0400
Subject: [Ns-bugs] [Bug 691] times function unsupported on mingw
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=691
--- Comment #3 from Mathieu Lacage 2009-10-20 05:46:39 EDT ---
Created an attachment (id=635)
--> (http://www.nsnam.org/bugzilla/attachment.cgi?id=635)
patch form gustavo
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Oct 20 02:46:57 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 20 Oct 2009 05:46:57 -0400
Subject: [Ns-bugs] [Bug 691] times function unsupported on mingw
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=691
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |705
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Oct 20 02:46:57 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 20 Oct 2009 05:46:57 -0400
Subject: [Ns-bugs] [Bug 705] netanim code does not build on win32
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=705
Mathieu Lacage changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mathieu.lacage at sophia.inria.
| |fr
Depends on| |691
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Oct 20 04:17:39 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 20 Oct 2009 07:17:39 -0400
Subject: [Ns-bugs] [Bug 726] New: Build failed OSX, CalendarScheduler
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=726
Summary: Build failed OSX, CalendarScheduler
Product: ns-3
Version: pre-release
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: build system
AssignedTo: ns-bugs at isi.edu
ReportedBy: meros.b6 at gmx.de
Estimated Hours: 0.0
I tested around with the not working Build on Mac OSX (10.4).
System is: Osx 10.4, gcc 4.0.x, Python tested: 2.5.x, 2.6.x!
Ways of building: using ./build.py, and do ./waf configure; /waf
Mostly the build vas iinterupted at [409/853] RC3 release candidate, also
tested ns-3.4, ns-3.5.1, ns-3.6-RC3, ns-3.6-RC4
with ./waf configuration: "CXXFLAGS="-O3" ./waf configure,"./waf configure
./waf", "./waf --with-nsc --enable-sudo build", "CXXFLAGS="" ./waf configure"
Configuration alway give this:
Macintosh-6:/ns3/ns-allinone-3.6-RC3/ns-3.6-RC3 hannes$ CXXFLAGS="-O3" ./waf
configure
Checking for program g++ : ok /usr/bin/g++
Checking for program cpp : ok /usr/bin/cpp
Checking for program ar : ok /usr/bin/ar
Checking for program ranlib : ok /usr/bin/ranlib
Checking for g++ : ok
Checking for program pkg-config : not found
Checking for regression reference traces : ok ../ns-3.6-RC3-ref-traces
(guessed)
Checking for header stdlib.h : ok
Checking for header signal.h : ok
Checking for header pthread.h : ok
Checking for high precision time implementation : 128-bit integer
Checking for header stdint.h : ok
Checking for header inttypes.h : ok
Checking for header sys/inttypes.h : not found
Checking for library rt : not found
Checking for header netpacket/packet.h : not found
Checking for header linux/if_tun.h : not found
Checking for library sqlite3 : ok
Checking for NSC location : not found
Checking for program python : ok
/Library/Frameworks/Python.framework/Versions/Current/bin/python
Checking for Python version >= 2.3 : ok 2.5.4
Checking for library python2.5 : not found
Checking for library python2.5 : ok
Checking for program python2.5-config : ok
/Library/Frameworks/Python.framework/Versions/Current/bin/python2.5-config
Checking for header Python.h : ok
Checking for -fvisibility=hidden support : yes
Checking for pybindgen location : not found
Checking for Python module pybindgen : not found
pybindgen missing => no python bindings
Checking for program sudo : ok /usr/bin/sudo
Checking for program hg : not found
Checking for program valgrind : not found
---- Summary of optional NS-3 features:
Threading Primitives : enabled
Real Time Simulator : not enabled (librt is not available)
Emulated Net Device : not enabled ( include not
detected)
Tap Bridge : not enabled ( include not
detected)
GtkConfigStore : not enabled (library 'gtk+-2.0 >= 2.12' not
found)
XmlIo : not enabled (library 'libxml-2.0 >= 2.7' not
found)
SQlite stats data output : enabled
Network Simulation Cradle : not enabled (NSC not found (see option
--with-nsc))
Python Bindings : not enabled (PyBindGen missing)
Use sudo to set suid bit : not enabled (option --enable-sudo not selected)
Build examples and samples : enabled
Static build : not enabled (option --enable-static not
selected)
GNU Scientific Library (GSL) : not enabled (GSL not found)
'configure' finished successfully (5.887s)
--> with python Bindings at Version ns-3.4
The error That allways occure:
[291/613] cxx: src/simulator/calendar-scheduler.cc ->
build/debug/src/simulator/calendar-scheduler_1.o
cc1plus: warnings being treated as errors
../src/simulator/calendar-scheduler.cc: In member function `virtual
ns3::Scheduler::Event ns3::CalendarScheduler::PeekNext() const':
../src/simulator/calendar-scheduler.cc:128: warning: converting of negative
value '-0x00000000000000001' to 'uint64_t'
../src/simulator/calendar-scheduler.cc:128: warning: converting of negative
value '-0x00000000000000001' to 'uint32_t'
../src/simulator/calendar-scheduler.cc: In member function
`ns3::Scheduler::Event ns3::CalendarScheduler::DoRemoveNext()':
../src/simulator/calendar-scheduler.cc:155: warning: converting of negative
value '-0x00000000000000001' to 'uint64_t'
../src/simulator/calendar-scheduler.cc:155: warning: converting of negative
value '-0x00000000000000001' to 'uint32_t'
Build failed
-> task failed (err #1):
{task: cxx calendar-scheduler.cc -> calendar-scheduler_1.o}
Traceback (most recent call last):
File "./build.py", line 106, in
sys.exit(main(sys.argv))
File "./build.py", line 97, in main
build_ns3(config)
File "./build.py", line 56, in build_ns3
run_command(["python", "waf"])
File "/ns3/ns-allinone-3.4/util.py", line 24, in run_command
raise CommandError("Command %r exited with code %i" % (argv, retval))
util.CommandError: Command ['python', 'waf'] exited with code 1
NOW I found a Combination that works:
Python 2.5, ns-3 and CXXFLAGS="-O3" ./waf configure
But when running the tests it looks like this:
./test.py
Waf: Entering directory `/ns3/ns-allinone-3.6-RC3/ns-3.6-RC3/build'
[748/853] cxx: examples/routing/nms-p2p-nix.cc ->
build/debug/examples/routing/nms-p2p-nix_10.o
../examples/routing/nms-p2p-nix.cc: In function `int main(int, char**)':
../examples/routing/nms-p2p-nix.cc:44: internal compiler error: in
cp_tree_equal, at cp/tree.c:1679
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Waf: Leaving directory `/ns3/ns-allinone-3.6-RC3/ns-3.6-RC3/build'
Build failed
-> task failed (err #1):
{task: cxx nms-p2p-nix.cc -> nms-p2p-nix_10.o}
CRASH: Example csma/csma-bridge
CRASH: Example csma/csma-bridge-one-hop
CRASH: Example csma/csma-broadcast
CRASH: Example csma/csma-multicast
CRASH: Example csma/csma-one-subnet
CRASH: Example csma/csma-packet-socket
CRASH: Example csma/csma-ping
CRASH: Example csma/csma-raw-ip-socket
CRASH: Example csma/csma-star
CRASH: Example error-model/simple-error-model
CRASH: Example ipv6/icmpv6-redirect
CRASH: Example ipv6/ping6
CRASH: Example ipv6/radvd
CRASH: Example ipv6/radvd-two-prefix
CRASH: Example ipv6/test-ipv6
CRASH: Example mesh/mesh
CRASH: Example naming/object-names
CRASH: Example routing/dynamic-global-routing
CRASH: Example routing/global-injection-slash32
CRASH: Example routing/global-routing-slash32
CRASH: Example routing/mixed-global-routing
CRASH: Example routing/nix-simple
CRASH: Example routing/simple-alternate-routing
CRASH: Example routing/simple-global-routing
CRASH: Example routing/simple-point-to-point-olsr
CRASH: Example routing/simple-routing-ping6
CRASH: Example routing/static-routing-slash32
CRASH: Example stats/wifi-example-sim
CRASH: Example tcp/star
CRASH: Example tcp/tcp-large-transfer
CRASH: Example tcp/tcp-star-server
CRASH: Example tunneling/virtual-net-device
CRASH: Example tutorial/first
CRASH: Example tutorial/hello-simulator
CRASH: Example tutorial/second
CRASH: Example tutorial/third
CRASH: Example tutorial/fourth
CRASH: Example udp/udp-echo
CRASH: Example wireless/mixed-wireless
CRASH: Example wireless/simple-wifi-frame-aggregation
CRASH: Example wireless/wifi-ap --verbose=0
CRASH: Example wireless/wifi-simple-adhoc
CRASH: Example wireless/wifi-simple-adhoc-grid
CRASH: Example wireless/wifi-simple-infra
CRASH: Example wireless/wifi-simple-interference
CRASH: Example wireless/wifi-wired-bridging
0 of 46 tests passed (0 passed, 0 skipped, 0 failed, 46 crashed, 0 valgrind
errors)
Can somebody give me hind how to build ns-3?
Thank you
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Oct 20 07:28:10 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 20 Oct 2009 10:28:10 -0400
Subject: [Ns-bugs] [Bug 728] New: FEC bloc size is not standard compliant
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=728
Summary: FEC bloc size is not standard compliant
Product: ns-3
Version: ns-3-dev
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: wimax
AssignedTo: ns-bugs at isi.edu
ReportedBy: amine.ismail at sophia.inria.fr
CC: amine.ismail at sophia.inria.fr
Estimated Hours: 0.0
The FEC bloc size is always 320 bits whatever the the chosen modulation
It should depend on the modulation and coding scheme as specified by Table 215
(Mandatory channel coding per modulation) 802.16-2004
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Oct 20 07:37:02 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 20 Oct 2009 10:37:02 -0400
Subject: [Ns-bugs] [Bug 728] FEC bloc size is not standard compliant
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=728
Mohamed Amine ISMAIL changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #1 from Mohamed Amine ISMAIL 2009-10-20 10:37:02 EDT ---
Fixed in changeset: 4571:a7e872481de6
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
From code at nsnam.ece.gatech.edu Tue Oct 20 09:38:29 2009
From: code at nsnam.ece.gatech.edu (code@nsnam.ece.gatech.edu)
Date: Tue, 20 Oct 2009 12:38:29 -0400
Subject: [Ns-bugs] [Bug 190] Reminder: NS_LOG_APPEND_CONTEXT
In-Reply-To:
References:
Message-ID:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=190
Tom Henderson changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tomh at tomh.org
--- Comment #1 from Tom Henderson 2009-10-20 12:38:29 EDT ---
Reminder on typical usage:
#define NS_LOG_APPEND_CONTEXT \
if (GetObject