Bug 49002 - PtrToStructure incorrectly marshaling structures with pack 1 attribute on armeabi-v7a
Summary: PtrToStructure incorrectly marshaling structures with pack 1 attribute on arm...
Alias: None
Product: Android
Classification: Xamarin
Component: General ()
Version: unspecified
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Jonathan Pryor
Depends on:
Reported: 2016-12-05 10:57 UTC by David Dunscombe
Modified: 2017-07-06 20:52 UTC (History)
2 users (show)

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

Example of PtrToStructure not marshaling data correctly for pack 1 structs (18.82 KB, application/x-zip-compressed)
2016-12-05 10:57 UTC, David Dunscombe

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 David Dunscombe 2016-12-05 10:57:51 UTC
Created attachment 18772 [details]
Example of PtrToStructure not marshaling data correctly for pack 1 structs

This is somewhat related to Bug 40665 but may be a different issue.

If a structure contains single byte fields and the structure is marked with the pack=1 StructLayoutAttribute when the field is subsequently read from the structure it will be incorrect, typically fields after the single byte value will be based upon data 1 out.

I've attached a sample project which shows the issue.

Also depending on how you access the field which is incorrect you sometimes get a nullreferenceexception.

This only affects Android on the device, the simulator seems OK.
Comment 1 David Dunscombe 2016-12-05 11:03:30 UTC
this is in the attached project, but for further info:

        [StructLayout(LayoutKind.Sequential, Pack = 1)]
        public struct BatchEntry
            public byte Marker0;
            public byte Marker1;
            public UInt16 Index;
            public UInt32 Time;

        [StructLayout(LayoutKind.Sequential, Pack = 1)]
        public struct Limits
            public float HighLimit;
            public byte PullToMaximum;
            public byte LimitsEnabled;

        [StructLayout(LayoutKind.Sequential, Pack = 1)]
        public struct CalibrationEntry
            public BatchEntry Header;
            public byte DollySize;
            public float TargetRate;
            public byte Cutter;
            public Limits Limits;
            public UInt32 HoldTime;
            public byte Layers;
            public byte Skirt;
            public byte ReadingRate;
            public UInt32 VeriticationDate;

given the byte array data 

            165, // CalibrationEntry.Header.Marker0
            2,   // CalibrationEntry.Header.Marker1
            0,   // CalibrationEntry.Header.Index
            0,   // CalibrationEntry.Header.Index
            0,   // CalibrationEntry.Header.Time
            0,   // CalibrationEntry.Header.Time
            0,   // CalibrationEntry.Header.Time
            0,   // CalibrationEntry.Header.Time
            2,   // CalibrationEntry.DollySize
            0,   // CalibrationEntry.TargetRate
            0,   // CalibrationEntry.TargetRate
            128, // CalibrationEntry.TargetRate
            63,  // CalibrationEntry.TargetRate

Marshalling data into CalibrationEntry and looking at the TargetRate field value in bytes is [0x00, 0x00, 0x80, 0x3F] which is 1.0 in IEEE754

If you look at the structure via the debugger it is indeed 1.0 after marshal.

However after passing the TargeRate field to a variable, the variable is set to -2.80259692864963E-45 which is [0x02, 0x00, 0x00, 0x80] in IEEE754

So it looks like the IL generated is accessing a field is 1 byte before that actual data.

Also if you do ToString() on TargetRate you get a NullReferenceException.
Comment 2 David Dunscombe 2016-12-05 11:19:52 UTC
It seems connected to single floats from further investigation, if you change the float to a UInt32 there is no wierdness.

So as a workaround i have created a dummy float type that seems to marshal properly.

        [StructLayout(LayoutKind.Sequential, Pack = 1)]
        public struct SafeMarshalFloat
            [MarshalAs(UnmanagedType.ByValArray, SizeConst = 4)]
            public byte[] Value;

            public SafeMarshalFloat(float value)
                Value = BitConverter.GetBytes(value);

            public static implicit operator float(SafeMarshalFloat value)
                return BitConverter.ToSingle(value.Value, 0);

            public static implicit operator SafeMarshalFloat(float value)
                return new SafeMarshalFloat(value);
Comment 3 Kent Green [MSFT] 2017-07-06 20:52:28 UTC
Thank you for taking the time to submit this report. After reviewing the description of this bug, we believe it no longer affects the current version of Xamarin.Android. If you are still experiencing the issue after updating your packages, please reopen this report with updated details of how to reproduce the issue. 

Specifically, I noted that in your attached sample, that the console is now reporting a value 1; which if I'm not mistaken is the correct behavior / expected outcome without this bug occurring:

> var structure = BytesToStructure<CalibrationEntry>(data);
> double target = structure.TargetRate;
> Console.WriteLine(structure.TargetRate.ToString());  // outputs 1; instead of NullReferenceException