Bug 1116

Summary:	int64x64 error
Product:	ns-3	Reporter:	Tommaso Pecorella <tommaso.pecorella>
Component:	core	Assignee:	Mathieu Lacage <mathieu.lacage>
Status:	RESOLVED INVALID
Severity:	critical	CC:	ns-bugs
Priority:	P5
Version:	ns-3-dev
Hardware:	All
OS:	All
Attachments:	config.log for ns-3 build

Description Tommaso Pecorella 2011-04-25 11:47:55 UTC

Created attachment 1097 [details]
config.log for ns-3 build

I was testing the programs for http://www.nsnam.org/bugzilla/﷒0﷓

In particular I fired the dsdv_mobile and the result was... astonishing.

aborted. cond="(hiPart & MASK_HI) != 0", msg="High precision 128 bits multiplication error: multiplication overflow.", file=../src/core/model/int64x64-128.cc, line=62

I added a few debug lines in int64x64-128.cc

  std::cout << "tring: " << double(a) << " x " << double(b) <<std::endl;
  std::cout << "hiPart: " << double(hiPart) << " loPart " << double(loPart) << std::endl;
  NS_ABORT_MSG_IF ((hiPart & MASK_HI) != 0,
		   "High precision 128 bits multiplication error: multiplication overflow.");

and the result is:

tring: 1.90994e+36 x 1.18255e+26
hiPart: 6.63741e+23 loPart 0
aborted. cond="(hiPart & MASK_HI) != 0", msg="High precision 128 bits multiplication error: multiplication overflow.", file=../src/core/model/int64x64-128.cc, line=62

Is this even close to be normal ? Is it an error in the simulation or in the build?

The core-config.h is:
/* Configuration header created by Waf - do not edit */
#ifndef _NS3_CORE_CONFIG_H_WAF
#define _NS3_CORE_CONFIG_H_WAF

/* #undef HAVE_UINT128_T */
#define HAVE___UINT128_T 1
#define INT64X64_USE_128 1
#define HAVE_STDINT_H 1
#define HAVE_INTTYPES_H 1
/* #undef HAVE_SYS_INT_TYPES_H */
#define HAVE_STDLIB_H 1
#define HAVE_GETENV 1
#define HAVE_SIGNAL_H 1
#define HAVE_PTHREAD_H 1
#endif /* _NS3_CORE_CONFIG_H_WAF */

Build info:
gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664)

System is set on 64 bit.

The full config.log is attached.

Comment 1 Tommaso Pecorella 2011-04-26 12:51:31 UTC

bump (because bugzilla was not sending e-mails)

Comment 2 Tommaso Pecorella 2011-05-07 13:56:24 UTC

Update on this bug.

The error appears to be in RoutingProtocol::GetSettlingTime
At one point the values of the operands are:

Route SettlingTime: 1.18329e+08 and LifeTime:0.0064106

The code is (with additional debug things):
          NS_LOG_DEBUG ("Route SettlingTime: " << mainrt.GetSettlingTime ().GetSeconds ()
                                               << " and LifeTime:" << mainrt.GetLifeTime ().GetSeconds ());
          Time temp = Time (m_weightedFactor * mainrt.GetSettlingTime ());
          NS_LOG_DEBUG ("Route SettlingTime * m_weightedFactor : " << temp.GetSeconds () );
          temp = temp + Time (1.0 - m_weightedFactor);
          NS_LOG_DEBUG ("prev + Time (1.0 - m_weightedFactor) : " << temp.GetSeconds () );
          temp =  Time (temp * mainrt.GetLifeTime ());
          weightedTime = Time ((m_weightedFactor * mainrt.GetSettlingTime () + 1.0 - m_weightedFactor)
                                * mainrt.GetLifeTime ());
          NS_LOG_DEBUG ("Calculated weightedTime:" << weightedTime.GetSeconds ());
          return weightedTime;

The partial operation results are:

Route SettlingTime * m_weightedFactor : 1.03538e+08
prev + Time (1.0 - m_weightedFactor) : 1.03538e+08
aborted. cond="(hiPart & MASK_HI) != 0", msg="High precision 128 bits multiplication error: multiplication overflow.", file=../src/core/model/int64x64-128.cc, line=57

The error is in the very last multiplication, operands are:
0x016fd74dadcbdd5d0000000000000000
0x000000000061d16a0000000000000000
(as they appear in "inline int64x64_t &operator *= (int64x64_t &lhs, const int64x64_t &rhs)".

Beside the fact that the previous operation should be double checked per-se, as I doubt it is right (if you check the result is an acceleration, seconds^2), the bug is still there.

The operation is "right" to be in overflow, but someone please explain why the cairo-based 128 multiplication is perfectly fine with this.

I suspect the bug is in the cairo version.

Comment 3 Tommaso Pecorella 2011-05-12 05:04:55 UTC

I checked with Tom and it seems he didn't had this overflow due to a "missing" bug in his ns-3 when he launched the AODV/DSDV tests.

The multiplication overflow is confirmed to be reproducible, hence it's not a bug per-se.

Closing the bug.