|
Bugzilla – Full Text Bug Listing |
| Summary: | "Test for possibly unreachable code-- please file a bug report if this is ever hit" | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Gustavo J. A. M. Carneiro <gjcarneiro> |
| Component: | internet | Assignee: | Tom Henderson <tomh> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gjcarneiro, ns-bugs |
| Priority: | P3 | ||
| Version: | ns-3-dev | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: |
gustavo's test case
patch to fix |
||
I think I see the problem-- I'll take this bug. Gustavo, I've spent a couple of hours trying to reproduce this event, and no luck. Can you easily provide a test program? I think it is safe to uncomment that FATAL_ERROR as a workaround. However, I'd like to understand how to get to that state in the code. Created attachment 282 [details]
gustavo's test case
So, the reason this triggers in the wifi case, and not the csma case, is that what is going on in this example is a Wifi::LinkUp() event that triggers an ArpCache flush. However, the WaitReplyTimer was left running, leading to the supposedly "unreachable" state. The attached patch will cancel the WaitReplyTimer when an ArpCache is flushed. The unreachable test can remain to see if we ever get another example. Created attachment 285 [details]
patch to fix
+1 changeset 761f94afe2a2 |
Guess what? :-) #0 0x00007f54dbb08f62 in ns3::ArpL3Protocol::Lookup (this=0xe4c610, packet=@0x421e6ed0, destination={m_address = 167837953}, device=@0x421e6ee0, cache=@0x421e6ec0, hardwareDestination=0x421e6fd0) at ../src/internet-stack/arp-l3-protocol.cc:224 224 NS_FATAL_ERROR ("Test for possibly unreachable code-- please file a bug report if this is ever hit"); In my case, I have a wifi node sending a flow to an AP; after a while I drag the node out of wifi range, and then after a short time that error occurs.