|
Bugzilla – Full Text Bug Listing |
| Summary: | endian issues with V4Ping application | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Tom Henderson <tomh> |
| Component: | core | Assignee: | Mathieu Lacage <mathieu.lacage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ns-bugs |
| Priority: | P3 | ||
| Version: | ns-3-dev | ||
| Hardware: | Mac powerpc | ||
| OS: | Mac OS | ||
I traced this today to some endian problems in the V4Ping application, where there are some assumptions made on the endianness (little-endian) of the machine. Specifically, line 133 of v4ping.cc; buf[] is little-endian but the other quantities may be little or big-endian. This fails on powerpc where it is compared against a big-endian quantity. (In reply to comment #1) > I traced this today to some endian problems in the V4Ping application, where > there are some assumptions made on the endianness (little-endian) of the > machine. Specifically, line 133 of v4ping.cc; buf[] is little-endian but the > other quantities may be little or big-endian. This fails on powerpc where it > is compared against a big-endian quantity. Hrm. This is funny. I believe that the code is buggy because of changeset 58ae52c5845f which is not complete. Let me explain: 1) the code was written originally by me to send _and_ read data in host order because the echo server is supposed to echo the data without interpreting it, you don't care what you write in the data field. So, the code was correct although it generated different traces on different systems. 2) craig made the code generate the same traces on different systems by making it write the data in a certain order (I don't know if it's little or big endian order but it's one of the two deterministically). 3) What you see is the fact that you write in a certain deterministic order but you read always in host (a non-deterministic) order. i.e., you need to either revert the patch from craig or add a matching ReadU32 function that does the symmetric from WriteU32 to read the node and application id.
> 3) What you see is the fact that you write in a certain deterministic order but
> you read always in host (a non-deterministic) order. i.e., you need to either
> revert the patch from craig or add a matching ReadU32 function that does the
> symmetric from WriteU32 to read the node and application id.
I opted for a similar Read32; changeset 623189bc65be
|
The cutover to the removal of ./waf regression in October revealed a latent bug which is causing the powerpc buildbot to fail since then. I'm filing this bug so as to not forget the details. The examples/csma/csma-ping.cc works differently on darwin-ppc. Specifically, this callback fails to execute. // finally, print the ping rtts. Config::Connect ("/NodeList/*/ApplicationList/*/$ns3::V4Ping/Rtt", MakeCallback (&PingRtt)); from examples/csma/csma-ping.cc works on our Linux boxes and on an Intel Mac, but not on the OS X PowerPC Mac for some reason. Because the csma-system test now counts these callback invocations, darwin-ppc test.py fails on test csma-system.