Bug 7896 - Debugging displays incorrect number
Summary: Debugging displays incorrect number
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Debugger ()
Version: 3.0.x
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Jeffrey Stedfast
URL:
Depends on:
Blocks:
 
Reported: 2012-10-18 10:07 UTC by Allie Miller
Modified: 2013-08-05 13:13 UTC (History)
2 users (show)

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

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:
Status:
RESOLVED FIXED

Description Allie Miller 2012-10-18 10:07:25 UTC
Similar to Bug 3216
Case #18576

Code being used:
decimal lat = System.Convert.ToDecimal(coordinate.Latitude);

In the debugger, the following displays:
lat = 52123 (without decimal point)

If you use System.Console.Writeln, the value is 52.123 (with a decimal point)

System Information:
MonoDevelop 3.0.4.7
Installation UUID: 3edb3c8b-1034-4172-8801-66a34af0f1c2
Runtime:
Mono 2.10.9 (tarball)
GTK 2.24.10
GTK# (2.12.0.0)
Package version: 210090011
Apple Developer Tools:
Xcode 4.5.1 (1842)
Build 4G1004
Monotouch: 6.0.4
Mono for Android: 4.2.6
Android SDK: /Users/hoffmann/Library/Developer/Xamarin/android-sdk-mac_x86
Supported Android versions:
1.6 (API level 4)
2.1 (API level 7)
2.2 (API level 8)
2.3 (API level 10)
3.1 (API level 12)
3.2 (API level 13)
4.0 (API level 14)
Java SDK: /usr
Build information:
Release ID: 30004007
Git revision: ea0108260c6a376ecaeffcdb7d03387bd51edda3
Build date: 2012-09-17 14:09:17+0000
Xamarin addins: ec43fd5cb223ead4234a9858d1b56eef03dad53a-dirty
Operating System:
Mac OS X 10.7.5
Darwin SAMSTAG-IMAC 11.4.2 Darwin Kernel Version 11.4.2
Thu Aug 23 16:25:48 PDT 2012
root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
Comment 1 Jeffrey Stedfast 2012-10-19 14:45:50 UTC
Looking over the debugger code for this, it looks like we call ToString() on the decimal value on the debugee, get back the string value in whatever the debugee's current CultureInfo is, then parse the string into a decimal value on the MonoDevelop side.

What is likely happening here is that the CurrentCulture on the debugee's side is not printing decimal places? Or possibly decimal.Parse() is not properly parsing the string returned from the decimal.ToString().
Comment 2 Jeffrey Stedfast 2012-10-19 15:35:37 UTC
Perhaps instead of calling ToString() on the debugee, we should call Decimal.GetBits () on the decimal value on the debugee, get back the int[] and then use that to create an identical decimal value locally (using the int[] .ctor).

I've implemented this in git master
Comment 3 Jeffrey Stedfast 2012-10-19 15:51:34 UTC
http://files.xamarin.com/~jeff/MonoDevelop-e017d4f59677563775649e7417dcc51261d7dc17.dmg

Could you try that build of MonoDevelop and see if that solves the issue?
Comment 4 Jeffrey Stedfast 2012-10-19 16:06:27 UTC
I knew it had to be something like this...

but I bet what is going on is this:

ToString() in the locale on your simulator or device is resulting in "52,123", and so when we use decimal.Parse() on that string (which assumes invariant culture) to create a local copy of the decimal value on the client side, it parses it as fifty-two thousand one hundred twenty three.

Anyways... using the Decimal.GetBits() approach should solve this.
Comment 5 Jeffrey Stedfast 2013-08-05 13:13:32 UTC
the GetBits() approach was implemented a while back, guess I forgot to close this