Bug 17495 - Array.Copy (FastCopy) path is copying the wrong data on ARM devices
Summary: Array.Copy (FastCopy) path is copying the wrong data on ARM devices
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: GC ()
Version: 3.2.x
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2014-01-29 19:32 UTC by Bassam
Modified: 2016-11-28 03:17 UTC (History)
6 users (show)

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


Attachments
test case (4.75 KB, application/octet-stream)
2014-01-29 19:32 UTC, Bassam
Details


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 GitHub or Developer Community 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 Bassam 2014-01-29 19:32:24 UTC
Created attachment 5938 [details]
test case

I’m chasing a bug while parsing the machine.config XML file, and I’ve narrowed it down to Array.Copy performing the wrong copy. Here’s an example of a buffer before and after the copy.

before copy '<descript'
after copy '< edcsirt'

The code that is doing this copy in in XmlTextReader.ReadTextReader:

	Console.WriteLine("before copy '{0}'", copysize, new string(peekChars, curNodePeekIndex, copysize));
	Array.Copy (peekChars, curNodePeekIndex,
	     peekChars, 0, copysize);
	curNodePeekIndex = 0;
	peekCharsIndex = copysize;
	Console.WriteLine("after copy '{0}'", new string(peekChars, 0, copysize));

As you can see the buffer is altered after its copied. This seems to happen only on newer versions of linux (3.4.6) on an armv5tel device. When running linux 2.6 I don’t see this.

I modified Array.Copy to not do a FastCopy and this issue goes away.

Test case attached. We're running latest mono from master (built with default config).
Comment 1 Zoltan Varga 2014-01-30 03:31:04 UTC
What kind of arm device is this ?
Comment 2 Bassam 2014-01-30 13:14:03 UTC
Here's the cpu info:

Processor name	: Feroceon 88F6282 rev 1 (v5l) @ 1.6 GHz 
BogoMIPS	: 1587.60
Features	: swp half thumb fastmult edsp 
CPU implementer	: 0x56
CPU architecture: 5TE
CPU variant	: 0x2
CPU part	: 0x131
CPU revision	: 1

Hardware	: Feroceon-KW ARM
Revision	: 0000
Serial		: 0000000000000000
Comment 3 Paolo Molaro 2014-01-31 09:39:39 UTC
Maybe on that kernel the unaligned fixup support has been broken or disabled by default. What is the value of /proc/cpu/alignment? (The file could be /proc/sys/debug/alignment as well).
Basically, on old arm cpus unaligned loads will cause bytes to be swapped/scrambled as in your test output, but all the latest versions of Linux should have the fixup enabled by default.
Comment 4 Brandon White 2014-01-31 10:02:59 UTC
I have encountered this same issue on a Technologic Systems TS4712 ARMv5 system when using the mono package from Debian Experimental (3.2.3).

root@ts4700:/# uname -a
Linux ts4700 2.6.34-ts471x #88 PREEMPT Thu Aug 15 10:29:09 MST 2013 armv5tejl GNU/Linux

root@ts4700:/# cat /proc/cpu/alignment
User:           0
System:         9484
Skipped:        0
Half:           9483
Word:           0
DWord:          1
Multi:          0
User faults:    0 (ignored)
Comment 5 Paolo Molaro 2014-01-31 10:19:40 UTC
Thanks Brandon, do
 echo 2> /proc/cpu/alignment
and see if that fixes the issue for you.
Comment 6 Bassam 2014-01-31 12:19:30 UTC
I can validate that setting alignment to 2 fixes the issue.

I can go back to the OEM and ask them to make sure the alignment is set correctly.

Is this this something that needs to be documented in the man page? Or even better, can mono become resilient to the different settings.
Comment 7 Brandon White 2014-02-03 13:10:38 UTC
Paolo, the `echo 2 > /proc/cpu/alignment` resolved the issue for me as well.  Thanks so much.
Comment 8 Brandon White 2014-04-02 10:55:11 UTC
This should be fixed for the same reason as https://bugzilla.xamarin.com/show_bug.cgi?id=17152

I believe Rodrigo Kumpera's changes (https://github.com/mono/mono/commit/a2c41c347fb2d873da23800a677180ad3be4205b) addressed this problem.
Comment 9 Miguel de Icaza [MSFT] 2016-11-28 03:17:16 UTC
This looks like it was fixed.

Please reopen if this was not the case.