question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

UWP:Can not create doc in ARM phone

See original GitHub issue

Dear, 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:closed
  • Created 6 years ago
  • Comments:33 (18 by maintainers)

github_iconTop GitHub Comments

2reactions
borrrdencommented, Jul 13, 2017

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)

1reaction
borrrdencommented, Jun 20, 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 use StructLayout to force FLSliceResult 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.

Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found