Bug 15630 - -float.Epsilon Equals Zero
Summary: -float.Epsilon Equals Zero
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Debugger ()
Version: Trunk
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: master
Assignee: Jeffrey Stedfast
Depends on:
Reported: 2013-10-23 14:51 UTC by Tom Spilman
Modified: 2013-12-05 13:08 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Watch window in VS2012 vs Xamarin.iOS (20.93 KB, image/png)
2013-10-23 15:05 UTC, Tom Spilman

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Tom Spilman 2013-10-23 14:51:01 UTC

Comment 1 Tom Spilman 2013-10-23 14:55:34 UTC
We have some code that essentially equals this:

var prev = 0.0f;
var elapsed = 1.0f;
var time = Math.Max(prev - elapsed, -float.Epsilon);

On Microsoft C# on Windows desktop, Windows Store (ARM and X86), and Windows Phone the resulting time value is a negative non-zero value... -float.Epsilon.

On Xamarin.iOS this code returns zero.
Comment 2 Tom Spilman 2013-10-23 15:05:46 UTC
Created attachment 5218 [details]
Watch window in VS2012 vs Xamarin.iOS

The results from the watch window in VS2012 vs Xamarin.iOS.
Comment 3 Sebastien Pouliot 2013-10-29 17:15:23 UTC
That's weird since it works fine from the command line.

$ cat bug15630.cs 
using System;

class Program {
	static void Main ()
		Console.WriteLine (Single.Epsilon);
		Console.WriteLine (-Single.Epsilon);
		Console.WriteLine (-Single.Epsilon == 0f);
}$ mcs bug15630.cs 
$ mono --version
Mono JIT compiler version 3.2.3 ((no/8d3b4b7 Mon Sep 16 23:46:28 EDT 2013)
Copyright (C) 2002-2012 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:           normal
	SIGSEGV:       altstack
	Notification:  kqueue
	Architecture:  x86
	Disabled:      none
	Misc:          softdebug 
	LLVM:          yes(3.3svn-mono)
	GC:            sgen
$ mono bug15630.exe 

Now it does fail inside XS / debugger 

> ? Single.Epsilon
> ? -Single.Epsilon
> ? -Single.Epsilon == 0f

but it works in the iOS simulator (which also use Mono's JIT), e.g. the following unit test assert fails.

		public void EqualsTest () 
			Assert.AreEqual (-Single.Epsilon, 0f);


2013-10-29 17:12:29.648 monotouchtest[86829:80b] 	[FAIL] EqualsTest :   Expected: -1.40129846E-45f
  But was:  0.0f

So it looks like a debugger issue.
Comment 4 Tom Spilman 2013-10-29 17:31:44 UTC
I think this is more than a debugger issue.  It actually caused our app to fail to run correctly on an iPad with no debugger connected.  It was only thru debugging the app that I found this to be the cause for the failure.
Comment 5 Tom Spilman 2013-10-29 17:32:49 UTC
It could be I was running non-optimized debug code on the iPad at that time.  So it could be a bug in debug enabled code deployed to a device.  But not just a debugger failure.
Comment 6 Sebastien Pouliot 2013-10-29 17:37:07 UTC
That would likely be a different issue (since it fails on the debugger and works on the JIT'ed simulator) - but I'll try it on device to be 100% sure (since the device use the ARM AOT compiler).

Can you tell me what are your normal build options for devices ? e.g. which ARM procesor, LLVM enabled…

Also having all the version information might prove useful.

The easiest way to get exact version information is to use the "Xamarin Studio" menu, "About Xamarin Studio" item, "Show Details" button and copy/paste the version informations (you can use the "Copy Information" button).

note: I'll open a separate bug report if I can reproduce this on device (and keep this one for the debugger only). I'll add your email address on the c.c. list
Comment 7 Tom Spilman 2013-10-29 17:49:57 UTC
=== Xamarin Studio ===

Version 4.0.13 (build 38)
Installation UUID: b739e65d-f5b3-4dcc-84c1-2de0158d653a
	Mono 3.2.3 ((no/8d3b4b7)
	GTK+ 2.24.20 theme: Raleigh
	GTK# (
	Package version: 302030000

=== Apple Developer Tools ===

Xcode 5.0 (3332.25)
Build 5A1413

=== Xamarin.Mac ===

Xamarin.Mac: Not Installed

=== Xamarin.iOS ===

Version: (Business Edition)
Hash: 57edee2
Build date: 2013-04-10 18:05:51-0400

=== Xamarin.Android ===

Version: 4.8.3 (Starter Edition)
Android SDK: /Users/raybatts/Library/Developer/Xamarin/android-sdk-mac_x86
	Supported Android versions:
		2.1 (API level 7)
		2.2 (API level 8)
		2.3 (API level 10)
		3.1 (API level 12)
		4.0 (API level 14)
Java SDK: /usr
java version "1.6.0_65"
Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)

=== Build Information ===

Release ID: 400130038
Git revision: 07afec667f7be5d0ee511eb7115bbac6377fbae8
Build date: 2013-09-24 08:53:29+0000
Xamarin addins: 61140345a5b109633a94409edcbc7a4c19a425c6

=== Operating System ===

Mac OS X 10.8.5
Darwin Rays-Mac-mini.local 12.5.0 Darwin Kernel Version 12.5.0
    Sun Sep 29 13:33:47 PDT 2013
    root:xnu-2050.48.12~1/RELEASE_X86_64 x86_64
Comment 8 Tom Spilman 2013-10-29 17:50:46 UTC
The build is set to ARMv7 and we have LLVM is disabled.
Comment 9 Sebastien Pouliot 2013-10-29 18:02:01 UTC
Thanks for the extra details.

Debugger-wise Double has the same issue:

> ? Double.Epsilon
> ? -Double.Epsilon
> ? -Double.Epsilon == 0d

Both Single and Double seems to fail on ARMv7 (without LLVM). I'll validate other configurations later (on the separate bug report).
Comment 10 Jeffrey Stedfast 2013-10-30 14:52:59 UTC
I thought this was a runtime issue? If it's failing in the runtime, why is this filed against the debugger?
Comment 11 Sebastien Pouliot 2013-10-30 19:27:27 UTC
@Jeff there's a separate bug (#15802) for a similar issue that happens on some ARM processors but not others.

In this case the Watch and Immediate pads behave unlike the x86 JIT (on OSX, did not try any other OS) when debugging on the iOS simulator (that uses the same JIT). That's why this bug is filed under the debugger.
Comment 12 Jeffrey Stedfast 2013-12-05 13:08:41 UTC
Right... but the debugger has the runtime (on the device) evaluate the expression, so this is not being evaluated in the MonoDevelop process at all.

This will be fixed when the runtime on the device is fixed.