Bug#696060: mtr: StDev overflowed to negative

2017-11-13 Thread Bernhard Schmidt
Control: fixed -1 0.85-1

On Sun, Dec 16, 2012 at 04:44:04PM +0100, Rogier Wolff wrote:

> The variance, which is used to calculate the stdev, is stored in a
> 64-bit integer.
> 
> However, what we store there are the squares of the difference from
> the average. So if you have 70 second ping time (sometimes), the
> square of 7 miliseconds becomes 4900 million! Quite a lot, but
> unlikely to overflow a 64-bit value However the calculation is
> done in microseconds Thus your 70 seconds is 70 million
> microseocnds, giving 4900 trillion (4.9 * 10^15) added to the running
> total every second or so, (as long as the average remains around
> zero). This can overflow a 64-bit variable in human-observable time.
> 
> I've modified the code to do the calculations in miliseconds from now
> on. This should buy us a factor of a million of margin. :-)

So, if I'm not mistaken this is
https://github.com/traviscross/mtr/commit/bc39728995df74dd0ab78feea9a8ecfc53579fce
and was ultimately included in 0.83. Marking the first Debian version
that has the fix.

Bernhard



Bug#696060: mtr: StDev overflowed to negative

2012-12-16 Thread The Wanderer

Package: mtr
Version: 0.82-3
Severity: minor

Dear Maintainer,

As part of an effort to diagnose - and later to confirm the fix of - an
ongoing network problem, I have maintained an mtr session running for
several weeks straight.

The current overall summary for one hop in that session presently reads
as follows:

  HostnameLoss  Rcv  Snt  Last   Best  Avg  Worst  StDev
  73.223.7.1  0.3%  4028069  4039341   687 12   60593  -2147483.75

The standard deviation value is negative, which is meaningless AFAIK,
and therefore should not be possible. The specific negative value in
question looks at a glance like the result of an overflow.

I am not clear on exactly what it would take to reproduce this problem.
Presumably, unreasonably high worst-case ping times in what is otherwise
a normal network environment would be at least a contributing factor.
However, I am relatively certain that I recall past sessions where this
hop has shown a Worst value of over 7 milliseconds, but the StDev
value has remained positive; as such, I am not sure whether that would
be sufficient.

This bug is of course extremely minor, as even if it does occur
reproducibly, the circumstances for it are rare and it is unlikely to
have more than a cosmetic effect even when it does occur. However, as it
is still a bug, I felt it worth reporting anyway.

If there is anything I can do to help to track this down, please don't
hesitate to let me know.


-- System Information:
Debian Release: wheezy/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-3-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mtr depends on:
ii  libatk1.0-0 2.4.0-2
ii  libc6   2.13-35
ii  libcairo2   1.12.2-2
ii  libfontconfig1  2.9.0-7
ii  libfreetype62.4.9-1
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.33.12+really2.32.4-3
ii  libgtk2.0-0 2.24.10-2
ii  libncurses5 5.9-10
ii  libpango1.0-0   1.30.0-1
ii  libtinfo5   5.9-10

mtr recommends no packages.

mtr suggests no packages.

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#696060: mtr: StDev overflowed to negative

2012-12-16 Thread Rogier Wolff

Hi, 

The variance, which is used to calculate the stdev, is stored in a
64-bit integer.

However, what we store there are the squares of the difference from
the average. So if you have 70 second ping time (sometimes), the
square of 7 miliseconds becomes 4900 million! Quite a lot, but
unlikely to overflow a 64-bit value However the calculation is
done in microseconds Thus your 70 seconds is 70 million
microseocnds, giving 4900 trillion (4.9 * 10^15) added to the running
total every second or so, (as long as the average remains around
zero). This can overflow a 64-bit variable in human-observable time.

I've modified the code to do the calculations in miliseconds from now
on. This should buy us a factor of a million of margin. :-)

Roger. 



On Sun, Dec 16, 2012 at 08:30:28AM -0500, The Wanderer wrote:
 Package: mtr
 Version: 0.82-3
 Severity: minor
 
 Dear Maintainer,
 
 As part of an effort to diagnose - and later to confirm the fix of - an
 ongoing network problem, I have maintained an mtr session running for
 several weeks straight.
 
 The current overall summary for one hop in that session presently reads
 as follows:
 
   HostnameLoss  Rcv  Snt  Last   Best  Avg  Worst  StDev
   73.223.7.1  0.3%  4028069  4039341   687 12   60593  -2147483.75
 
 The standard deviation value is negative, which is meaningless AFAIK,
 and therefore should not be possible. The specific negative value in
 question looks at a glance like the result of an overflow.
 
 I am not clear on exactly what it would take to reproduce this problem.
 Presumably, unreasonably high worst-case ping times in what is otherwise
 a normal network environment would be at least a contributing factor.
 However, I am relatively certain that I recall past sessions where this
 hop has shown a Worst value of over 7 milliseconds, but the StDev
 value has remained positive; as such, I am not sure whether that would
 be sufficient.
 
 This bug is of course extremely minor, as even if it does occur
 reproducibly, the circumstances for it are rare and it is unlikely to
 have more than a cosmetic effect even when it does occur. However, as it
 is still a bug, I felt it worth reporting anyway.
 
 If there is anything I can do to help to track this down, please don't
 hesitate to let me know.
 
 
 -- System Information:
 Debian Release: wheezy/sid
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386
 
 Kernel: Linux 3.2.0-3-amd64 (SMP w/12 CPU cores)
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages mtr depends on:
 ii  libatk1.0-0 2.4.0-2
 ii  libc6   2.13-35
 ii  libcairo2   1.12.2-2
 ii  libfontconfig1  2.9.0-7
 ii  libfreetype62.4.9-1
 ii  libgdk-pixbuf2.0-0  2.26.1-1
 ii  libglib2.0-02.33.12+really2.32.4-3
 ii  libgtk2.0-0 2.24.10-2
 ii  libncurses5 5.9-10
 ii  libpango1.0-0   1.30.0-1
 ii  libtinfo5   5.9-10
 
 mtr recommends no packages.
 
 mtr suggests no packages.
 
 -- no debconf information
 

-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#696060: mtr: StDev overflowed to negative

2012-12-16 Thread The Wanderer

On 12/16/2012 10:44 AM, Rogier Wolff wrote:


Hi,

The variance, which is used to calculate the stdev, is stored in a 64-bit
integer.

However, what we store there are the squares of the difference from the
average. So if you have 70 second ping time (sometimes), the square of 7
miliseconds becomes 4900 million! Quite a lot, but unlikely to overflow a
64-bit value However the calculation is done in microseconds Thus
your 70 seconds is 70 million microseocnds, giving 4900 trillion (4.9 *
10^15) added to the running total every second or so, (as long as the average
remains around zero). This can overflow a 64-bit variable in human-observable
time.


The case at hand was only about 6 milliseconds, but yes, that would explain
the problem.

The fact that I've seen 7-millisecond Worst times without seeing this
problem would then be explained by the fact that those sessions didn't last this
long; IIRC they were about two weeks at most, and this one is over six.


I've modified the code to do the calculations in miliseconds from now on.
This should buy us a factor of a million of margin. :-)


Not a 100% fix in theory, but it should hide the problem for pretty much any
case that's actually reasonable to support.

Sounds good to me; thanks for the prompt response!


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org