Bug 1029 - endian issues with V4Ping application
endian issues with V4Ping application
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: core
ns-3-dev
Mac powerpc Mac OS
: P3 normal
Assigned To: Mathieu Lacage
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-12 13:05 EST by Tom Henderson
Modified: 2010-12-30 14:21 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Henderson 2010-11-12 13:05:13 EST
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.
Comment 1 Tom Henderson 2010-12-29 18:11:15 EST
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.
Comment 2 Mathieu Lacage 2010-12-30 03:47:34 EST
(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.
Comment 3 Tom Henderson 2010-12-30 14:21:49 EST
> 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