In my Android native app created with Xamarin, I get the following crash report in HockeyApp:
Xamarin caused by: android.runtime.JavaProxyThrowable: System.NullReferenceException: Object reference not set to an instance of an object at System.Threading.Tasks.RangeWorker.FindNewWork (System.Int64& nFromInclusiveLocal, System.Int64& nToExclusiveLocal) [0x00000] in <8f1acca5a43d45c5b8d35add5a11806a>:0 at System.Threading.Tasks.RangeWorker.FindNewWork32 (System.Int32& nFromInclusiveLocal32, System.Int32& nToExclusiveLocal32) [0x00000] in <8f1acca5a43d45c5b8d35add5a11806a>:0 at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () <0xec919968 + 0x00033> in <8f1acca5a43d45c5b8d35add5a11806a>:0 I cannot figure out what is causing this exception since the stack trace only contains .net code. I have looked at the framework's source code to see if I could make sense of it but to no avail.
I have also tried many different searches in my favorites search engines without finding any posts/articles about similar issues.
From the data associated with those crashes, it seems to be an issue happening exclusively on Samsung devices (S8, S8+ and Note8). I cannot be 100% sure that it doesn't affect other devices but I only have crash reports for those.
Any idea what could cause those crashes? Am I doing something wrong with threading, maybe with cancellation tokens? Are there conditions I am not handling correctly?
Any help to further troubleshoot this issue would be very welcomed.
Thank you
EDIT:
I understand that there is not much to go by but being that this is the only stacktrace I get in HockeyApp and I cannot repro, I have no idea what code causes this.
What I am looking for is more a clue about what could cause Mono threading code to have a null reference exception when I am not managing the threads myself. Or maybe this stacktrace is just a red herring and I need to be looking in other places?
3 Answers
Answers 1
What caught my attention was the FindNewWork32 call -- link for the .NET implementation. Your app may be compiled for 32-bit architecture, and those Samsung devices you mentioned have a 64-bit processor.
This Microsoft paper shows how to target an app to one or more Android-supported CPU architectures. You may need to target multiple platforms:
To target multiple CPU architectures, you can select more than one ABI (at the expense of larger APK file size). You can use the Generate one package (.apk) per selected ABI option (described in Set Packaging Properties) to create a separate APK for each supported architecture.
You do not have to select arm64-v8a or x86_64 to target 64-bit devices; 64-bit support is not required to run your app on 64-bit hardware. For example, 64-bit ARM devices (such as the Nexus 9) can run apps configured for armeabi-v7a. The primary advantage of enabling 64-bit support is to make it possible for your app to address more memory.
Answers 2
I know this answer is not specific for your issue, but when you are dealing with an exception message, which is so brief, it's always a good idea to check system-wide logging. In case of Android, you might get more information using dmesg command (which is giving you the content of /var/log/messages file).
Good luck
Answers 3
You should call .IsCompleted or .Wait() soon after callback. If you do it before the Context objects might go away and if your code is accessing those Context objects will be arbitrarily null (removed). If you call Task.Wait() it would block the thread and then throw an AggregateException once the worker throws it. Try using try catch block to handle exception.
Issue JavaProxyThrowable not always happening due to calling service there might be your activity null some where. You should check null before using activity context.
0 comments:
Post a Comment