Rare unusual crash where public static readonly variables are null

JahmaiJahmai AUMember ✭✭

I'm experiencing a semi-rare issue where accessing public static readonly instances is throwing NullReferenceException.

I really don't know where to begin trying to figure this out, and my attempts to reproduce it reliably have failed.

I know it's happening from crash reports provided from Crashlytics, and by occasional log entries during development.

Here is a sample of what the problem code looks like:

    public class MySingleton
    {
        public static readonly MySingleton Instance = new MySingleton();
    }

The caller will do MySingleton.Instance, and it will throw NullReferenceException.

The greater mystery is that it can succeed for some time and then fail later.

Currently occurring on Xamarin iOS 7.2.3, both in Release (llvm/sgen/refcount/type sharing) and Debug (sgen/refcount/type sharing).

Anyone experienced this or have any ideas on how I might create a test case for it?

Best Answers

Answers

  • JahmaiJahmai AUMember ✭✭

    I think this issue may share the same root cause as this bug: https://bugzilla.xamarin.com/show_bug.cgi?id=16489

  • JahmaiJahmai AUMember ✭✭

    Minor correction, the last recorded example of this was with 7.2.0. I don't presently have evidence of it occurring on 7.2.3, even though I feel sure it has.

  • OZGURAKSUOZGURAKSU TRMember

    I am experiencing a rare but very real problem with Xamarin.iOS 8.4.0.16 when trying int to string conversion. It is so rare that I cannot reproduce it myself. But in production it occurs about 8% of the time, seemingly with faster devices.

    Saw your post on https://bugzilla.xamarin.com/show_bug.cgi?id=16489

    I'm trying to figure out how to fix this. I thought of making an initial call to let the static constructor finish. But I have no way of knowing if this will fix it, because I cannot reproduce on my devices!

  • OZGURAKSUOZGURAKSU TRMember
    edited November 2014

    Actually my idea would not fix this problem. How the heck do you make sure static readonly variables inside a private class are initialized!? In other words, how to make this not return null??

    namespace System { static class EmptyArray<T> { public static readonly T[] Value = new T [0]; } }

  • RolfBjarneKvingeRolfBjarneKvinge USXamarin Team Xamurai

    @OZGURAKSU‌: can you post stack traces / crash reports?

  • OZGURAKSUOZGURAKSU TRMember
    edited November 2014

    @RolfBjarneKvinge‌ Hi Rolf. I have limited reporting from Production so stack trace is limited but clear enough:

    Object reference not set to an instance of an object at System.NumberFormatter.ResetCharBuf (Int32 size) [0x00000] in <filename unknown>:0 at System.NumberFormatter.FastIntegerToString (Int32 value, IFormatProvider fp) [0x00000] in <filename unknown>:0

    Looking at Mono's source I have identified that a call to EmptyArray<char>.Value must be returning null. I'm attempting a fix by calling ToString on an Int32 prior to any thread launches, but I don't have enough detailed know-how to be sure this will be a fix. Maybe you could comment.

    As I've mentioned, I am not able to reproduce this on the devices available to me. I can tell you the devices that had this error on launch so far:

    iPad Air iPad (4th generation) iPhone 5

    iOS versions:
    7.1.2 8.1

    NOTE: Second launch on some of these worked fine.

  • RolfBjarneKvingeRolfBjarneKvinge USXamarin Team Xamurai

    @OZGURAKSU‌: yeah, looks like you're running into bug #16489.

    You can always try to call ToString on an Int32 prior to any thread launching, but my initial hunch would be that it won't help (I think somehow that static field got nulled out, and nothing will make it change back).

    My advice would be to reopen that bug report, and ask for ideas how to help track it down.

  • OZGURAKSUOZGURAKSU TRMember

    @RolfBjarneKvinge‌ Actually there is another bug report confirmed that is still open here:
    https://bugzilla.xamarin.com/show_bug.cgi?id=23242

    I wish I understood Zoltan's comment at the end there.

  • OZGURAKSUOZGURAKSU TRMember

    @RolfBjarneKvinge‌ You may be right about it being somehow set to null. Because I observed now that it happens during regular app usage even after initialization. That means there's nothing I can do at this time short of avoiding ToString, which is not an option. Thanks anyway Rolf. I will reopen that bug to hopefully get some attention to this.

  • RolfBjarneKvingeRolfBjarneKvinge USXamarin Team Xamurai

    @OZGURAKSU: Zoltan's comment is about Mono internals, there's no need to understand it (there's nothing you can do on your side).

    I can also reproduce the issue on my Mac with the test case from bug #23242.

  • OZGURAKSUOZGURAKSU TRMember

    @RolfBjarneKvinge‌ That's good news. Thanks very much Rolf. I appreciate it.

  • OZGURAKSUOZGURAKSU TRMember

    @RolfBjarneKvinge‌ Rolf can I ask you a question? I noticed that you had LLVM enabled for your test. Marek before you didn't and they didn't run into it. I had also used LLVM to help improve performance. Could disabling LLVM make the difference?

  • OZGURAKSUOZGURAKSU TRMember

    To anyone reading this with similar problems: I suspect LLVM is the culprit, but I will not know for sure until I release my fix and see the results. I have encountered Null Exceptions in non-static variables as well and thought it was an application bug but some variables that should not be null are being set to null somehow. I'd advise anyone reading this to thoroughly test LLVM compiled binaries, especially if you are making extensive use of background threads and/or have an event-driven architecture as I do.

  • JahmaiJahmai AUMember ✭✭

    Just wanted to chime in and say that yes, we still get variations of this crash from time to time. We had to disable things like logging in our released apps (which used int.ToString() frequently) to reduce how often it happened. Frankly I am a bit disappointed it took this long for anyone from Xamarin to reply to this thread.

  • JahmaiJahmai AUMember ✭✭

    @OZGURAKSU We also use LLVM, but I can't recall if this started happening before or after we enabled it. I've only reproduced this accidentally a couple of times during development, so it's extremely hard to build a test case around. Every time we release a new version of our app with a new Xamarin.iOS version, it happens in the wild atleast a half dozen times in the first couple of weeks with various configurations and devices.

  • OZGURAKSUOZGURAKSU TRMember
    edited November 2014

    @Jahmai‌ Since there is not much else to do, I'd rather sacrifice the performance improvement than lose customers due to arbitrary exceptions at this time. I'm going to try disabling LLVM and I will report back on this thread whether or not this indeed was the problem.

  • JahmaiJahmai AUMember ✭✭

    @OZGURAKSU Very reasonable course of action. Look forward to hearing about the result. Thanks.

  • JahmaiJahmai AUMember ✭✭

    Thanks Rolf, what Xamarin.iOS release can we expect this in?

  • JahmaiJahmai AUMember ✭✭

    Thanks

  • OZGURAKSUOZGURAKSU TRMember

    FYI I'm not seeing any error with the LLVM-disabled update.

  • OZGURAKSUOZGURAKSU TRMember

    Actually I did see it again. It is really random. So it's probably not LLVM issue.

  • RolfBjarneKvingeRolfBjarneKvinge USXamarin Team Xamurai

    @Jahmai: The fix will be included in Xamarin.iOS 8.6.

  • JahmaiJahmai AUMember ✭✭

    @RolfBjarneKvinge‌ Great! Any idea when that might be? ;)

  • RolfBjarneKvingeRolfBjarneKvinge USXamarin Team Xamurai

    @Jahmai: the first Alpha should be out this week, and the Stable release is planned for early January.

  • OZGURAKSUOZGURAKSU TRMember

    @RolfBjarneKvinge‌ Thanks for that update Rolf.

Sign In or Register to comment.