4

How can a static readonly object become null? (I've set the _lock object as static and not static, but always readonly.)

The validate method works fine for a few times, then after it's called 2-3 times the _lock object is null. Is this an indicator that the lock is owned by another thread?

enter image description here

  • 2
    Well, this can happen if you were to abuse reflection. You are confident nothing in your code could conceivably be doing so? (`typeof(YourClass).GetField("_lock", BindingFlags.NonPublic | BindingFlags.Static).SetValue(null, null)` will set the field to null) – Kirk Woll Nov 27 '14 at 00:14
  • 2
    @Community: it's a valid question, please don't close it as "offtopic" since it's clearly not – zerkms Nov 27 '14 at 00:21
  • 4
    Can you try and reduce your code to a [minimal, complete and verifiable example](http://stackoverflow.com/help/mcve)? Remove code until either a) it's minimal and you can post it here, or b) the problem goes away and you find out the answer yourself. – dcastro Nov 27 '14 at 00:28
  • Take a peek at Marc Gravell's post [here](http://stackoverflow.com/questions/1861733/can-a-readonly-field-in-net-become-null?rq=1) and see if anything jumps out at you. – GEEF Nov 27 '14 at 00:30
  • Another couple of extreme edge cases Marc Gravell missed: [When is a readonly field not readonly?](http://joeduffyblog.com/2010/07/01/when-is-a-readonly-field-not-readonly/) by Joe Duffy. The second one is specially tricky – dcastro Nov 27 '14 at 00:36
  • 2
    What does Visual Studio say about the definition of `_lock`, where it has underlined the name? – poke Nov 27 '14 at 00:43
  • Can you set a breakpoint to trigger when the value of _lock changes? See http://stackoverflow.com/questions/160045/break-when-a-value-changes-using-the-visual-studio-debugger – sevzas Nov 27 '14 at 00:49
  • @servas can't do that in C# afaik; it's only for unmanaged code. – Blorgbeard Nov 27 '14 at 01:13
  • 1
    You need to post a good code example. A screenshot of a couple of lines of code in the debugger isn't providing enough context for anyone to tell you what's going on. See http://stackoverflow.com/help/mcve – Peter Duniho Nov 27 '14 at 01:47
  • @poke: That's probably ReSharper telling him that `_lock` doesn't follow the naming rules for `static readonly` fields, and suggesting that it be named `Lock`. – Jim Mischel Nov 27 '14 at 02:20
  • Find all users of lock and make sure its not being sett'd to Null – DevEstacion Nov 27 '14 at 02:42
  • Sorry for late responses...It's Thanksgiving here. @KirkWoll I am not using reflection anywhere related to this code. I am trying to duplicate this, but outside of the scope of this project it works as expected. @ Everyone Else, I understand there's not much code here, but I am trying to approach this from a global perspective, i.e "What can cause a static readonly field to become null after it's initialized". If reflection is the only way, or apparently there's something else happening to it. I'll post some more code though to see if anything stands out. – Matthew Hilgenfeld Nov 27 '14 at 21:37
  • @poke yes, it's just resharper naming convention warning. – Matthew Hilgenfeld Nov 27 '14 at 21:39

1 Answers1

-4

Besides reflection, another of the ways that this (more specifically, a null reference exception on a static variable assigned via initializer) can happen is if you have a static constructor defined elsewhere in your class that for some reason sets the value to null, e.g.:

class Program
{
    class A
    {
        private static readonly object _lock = new object();

        public void Validate()
        {
            lock (_lock) // NullReferenceException here...
            {
                Console.WriteLine("Not going to make it here...");
            }
        }

        static A()
        {
            Console.WriteLine(_lock.ToString());
            Console.WriteLine("Now you can see that _lock is set...");
            _lock = null;
        }
    }

    static void Main(string[] args)
    {
        var a = new A();
        a.Validate();
    }
}
F.Buster
  • 88
  • 7
  • Ok so he said that, is it wrong to list another of ways it can happen then? – F.Buster Nov 27 '14 at 00:29
  • 1
    "of ways it can happen then" --- another ways of what "it"? Another ways to break the code intentionally? Your answer does not address the question in any way, sorry. – zerkms Nov 27 '14 at 00:31
  • He *says* that it works, but based on the screenshot, **it obviously does not** - so the question is why. One of these reasons that I have provided is probably why. – F.Buster Nov 27 '14 at 00:36
  • 1
    @F.Buster, but your reason could not possibly be the explanation for the OP's problem. Because if it ever worked, a static initializer setting the field to null could not be responsible. – Kirk Woll Nov 27 '14 at 00:38
  • @KirkWoll To be fair, since the question is missing detail, and this seems to be an edge case, it's fair to assume *nothing*. And that includes questioning the OP's assumptions too, such as "the validate method works fine for a few times". – dcastro Nov 27 '14 at 00:43
  • @dcastro, asking for clarification from the OP ("questioning the OP's assumptions") is what comments are for. Answering a question presuming that the OP's information is false is not terribly helpful, IMO. – Kirk Woll Nov 27 '14 at 00:44
  • @F.Buster, your second explanation is still impossible. The `_lock` field highlighted in the debugger was set to a non-null value during initialization. *That very same field* is what is being locked on -- they are both participating in the same scope for `_lock`. Therefore, the question for how that field could possibly ever be null after not being null is the same as with the OP's original scenario, without your nesting. – Kirk Woll Nov 27 '14 at 00:50
  • @Kirk - you are correct, I had a typo in my original program that made it appear to have the same behavior. Regardless, I have tried to clear up my answer for the original case I was describing. – F.Buster Nov 27 '14 at 05:19
  • @zerkms - does this latest edit help clear up what I'm describing? – F.Buster Nov 27 '14 at 05:20
  • @F.Buster: I don't think so. If OPs statement about "The validate method works fine for a few times" is right, then your answer does not explain it. – zerkms Nov 27 '14 at 05:31
  • I appreciate the response, but the only time this field is referenced in the entire project is those two lines...when it's created and on the lock. – Matthew Hilgenfeld Nov 27 '14 at 21:41