UWP:Can not create doc in ARM phone
See original GitHub issueDear, I’m using couchbase.lite in UWP project. The thing is that, I can not create doc in an ARM device. I have tested on two devices running build 14393. Note that it’s working properly on PC (tested debug_x86x64@build15063) and emulator(debug_x86@build14393,15063). The error code:
System.AccessViolationException occurred
HResult=0x80004003
Message=Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
Source=<Cannot evaluate the exception source>
StackTrace:
at Couchbase.Lite.Internal.Serialization.JsonFLValueWriter.Flush()
at Couchbase.Lite.Internal.Serialization.DefaultSerializer.Serialize(Object obj)
at Couchbase.Lite.Document.SaveInto(C4Document** outDoc, Boolean deletion, IDocumentModel model)
at Couchbase.Lite.Document.<>c__DisplayClass25_0.<Save>b__0()
at Couchbase.Lite.Database.<>c__DisplayClass68_0.<InBatch>b__0()
at Couchbase.Lite.Support.ThreadSafety.DoLocked(Action a)
at Couchbase.Lite.Database.InBatch(Action a)
at Couchbase.Lite.Document.Save(IConflictResolver resolver, Boolean deletion, IDocumentModel model)
at Couchbase.Lite.Document.<Save>b__22_0()
at Couchbase.Lite.Support.ThreadSafety.DoLocked(Action a)
at Couchbase.Lite.Document.Save()
at Couchbase.Lite.Database.<>c__DisplayClass71_0.<Save>b__0()
at Couchbase.Lite.Support.ThreadSafety.DoLocked(Action a)
at Couchbase.Lite.Database.Save(Document document)
at Core.Models.DBH.MakeDoc(IDictionary`2 Dic) in C:\Users\Mohsen\Source\Repos\Denna\Denna\Core\Models\DBH.cs:line 32
at Core.Models.UserModel.<CreateUser>d__0.MoveNext() in C:\Users\Mohsen\Source\Repos\Denna\Denna\Core\Models\UserModel.cs:line 50
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine)
at Core.Models.UserModel.CreateUser(String ID, String email, String Name, String Family, String pass)
at Denna.Views.UnitTests.Button_Click_1(Object sender, RoutedEventArgs e) in C:\Users\Mohsen\Source\Repos\Denna\Denna\Denna\Views\UnitTests.xaml.cs:line 105
Issue Analytics
- State:
- Created 6 years ago
- Comments:33 (18 by maintainers)
Top Results From Across the Web
Troubleshooting ARM UWP apps
To build your UWP application to natively target the Arm64 platform, ... Arm apps may run into problems when using mobile-only APIs (for ......
Read more >Unable to deploy a UWP app to a Windows Phone device
Create a blank dummy UWP app with min = 14393 and target = 16299. ... Error 0x80070003: The system cannot find the path...
Read more >DEP6701: The system cannot find the path specified 'Bin ...
I just ran a project on my side and started process monitor tool to check how the dbghelp.dll is involved during debugging on...
Read more >Crash debugging Windows 10 Mobile UWP apps
First off, make sure that Windows 10 Mobile will collect crash ... for debugging UWP apps on all platforms but I cannot say...
Read more >Official support for Windows 10 on ARM development
To start, update to Visual Studio 15.9. If you are going to build ARM64. After updating, for new UWP projects, you will see...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
There are no comments on the linked issue but it has been tagged for UWP 6.0. I didn’t quite know what this meant but then I realized that the current Nuget version of
Microsoft.NETCore.UniversalWindowsPlatform
is 5.3.3. I assume that means that this will be resolved with the 6.0 release (still listed as Q4 2017)I’ve discovered what is happening but I have no idea what to do about it yet. To call functions in C or C++ you need to make space on the stack to write the parameters and have a space for the return value. FLSliceResult (the return type for the function that is crashing) should be 8 bytes (4 bytes for a pointer, and 4 bytes for
size_t
on a 32-bit system) but for some reason it is reserving too much space for it (12 bytes). That means that the stack gets moved over too much, and the first argument is in the last 4 bytes of the “expected return value space” portion of the stack. Consequently, the 2nd argument is picked up as the first, and whatever junk is after that gets picked up as the second. If I useStructLayout
to forceFLSliceResult
to be 12 bytes then things work but that will likely break x86. Making a build for each will defeat the purpose of having a single .NET Standard DLL. I hope that someone on Stack Overflow or on the Microsoft forums will have an answer about this because this seems like a bug in the runtime.EDIT Just tested, and as I thought this approach breaks x86, which behaves correctly and expects a size of 8.