runtime: span.copyto(span) crashes at linux-arm64 platform in .net6
Description
HI everybody, i am using .net6. within the application using copyto to copy a span into a different span. it works fine if build and run on windows or ubuntu. but it crashed when deployed on linux-arm64.
generated private span: private byte[] _localDmaData; private Span<byte> LocalDmaBuffer => _localDmaData;
copy data into it: line 70: data.CopyTo(LocalDmaBuffer);
exception it get: External component has thrown an exception. at System.Buffer.Memmove(Byte& , Byte& , UIntPtr ) at …DataReceivedDataCallback(ReadOnlySpan`1 data) in …/code.cs:line 70
heavily appreciate any help or idea for the root-cause and fix.
Fabian
Reproduction Steps
private byte[] _localDmaData = new byte[1024]; private Span<byte> LocalDmaBuffer => _localDmaData;
private void DataReceivedDataCallback(ReadOnlySpan<byte> data) { data.CopyTo(LocalDmaBuffer); }
Expected behavior
copys data into new span without any complains
Actual behavior
External component has thrown an exception. at System.Buffer.Memmove(Byte& , Byte& , UIntPtr ) at …DataReceivedDataCallback(ReadOnlySpan`1 data) in …/code.cs:line 70
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
No response
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 18 (13 by maintainers)
Agree that it would be nice to switch this code to use Vector128 now that we have this capability.
Closing as expected behavior per @jkotas’s comment above.
I did not get the chance to run the debugger on the system. but i hope to get it done this week, and we also move the DMA memory location to a place that SIMD is happy. will keep you posted.
but in general it would be nice if the framework can take care of, and if it detects something like that, switches back to the core3.1 version of it.
Hi so the ReadOnlySpan<> handed to the Callback is a specific memory area defined in the device tree for the DMA to store data. so its in a non cachable area of the ddr4. the data source for the DMA is coming from an FPGA. we are using and Xilinx Ultrascale+ chip running Yocto (if that additional info may help)
i will take your code and put it onto the hardware later to reproduce it.
the same code did work on .netcore 3.1