0

It look like I have a JIT error (another one :/) :

I have this piece of code :

    private Boolean m_bIsLoaded = false;

    public Boolean IsLoaded
    {
        get { return this.m_bIsLoaded; }
        set { this.m_bIsLoaded = value; }
    }

    public long DocGedCourrier {
        get {
            if ((this.IsLoaded == false)) {
                this.Load();
            }
            return this.GetInt64Value("ID_DOCGEDCOURRIER");
        }
        set {
            this.SetValue("ID_DOCGEDCOURRIER", value);
            NotifyPropertyChanged("DocGedCourrier");
        }
    }

I'm running a windows service on a x64 platform (Windows XP service Pack 3) in debug, with no optimization.

When I attached the debugger remotely and I put a breakpoint on the this.Load() method, the debugger stop. If I look the value of this.IsLoaded, it's return True.

If I run the service without the debugger attached, the Load() function is always called even if IsLoaded == True.

If I run the service with the debugger attached, the Load() is not called when I debug step-by-step.

If I run the service on a x86 platform (Windows XP service Pack 3), it's work perfectly, with and without the debugger attached.

There is no way m_bIsLoaded could change because m_bIsLoaded is only set with the IsLoaded property and the set { this.m_bIsLoaded = value; } is only called once, with a IsLoaded = true.

I'm 99.99% sure it's a JIT error, because I already had this kind of problem (see also Variable is not incrementing in C# Release x64).

My question is :

How could I detect this kind of problem and avoid them definitely ?

Thank you,

Edit :

I add a lock to ensure IsLoaded is not modified by another thread :

    public readonly Object Lock = new Object();

    public virtual Object Load()
    {
        lock (Lock)
        {
            if ((IsLoaded))
            {
                return this;
            }
        }
               ...
    }

    public Boolean IsLoaded
    {
        get { return this.m_bIsLoaded; }
        set
        {
            lock (Lock)
            {
                this.m_bIsLoaded = value;
            }
        }
    }

It did not solve the problem. As you can see in this screen shoot : http://img15.hostingpics.net/pics/125986Screenshoot.jpg . Return this is not call even if IsLoaded is set to True.

I exclude the multi-thread access possibility. by the way, IsLoaded is only set to false when the field is initialised. If IsLoaded is True, there is no way it could have the False value anymore in my code.

What can I do to prevent this ?

Community
  • 1
  • 1
Filimindji
  • 1,453
  • 1
  • 16
  • 23
  • 1
    Try to set a breakpoint in the set part of IsLoaded property. When the debugger stops, look at your stack window to find who is calling the property – Steve Mar 12 '12 at 16:07
  • As I've mentionned, the set is called only once. I checked this using a breakpoint. The value assigned is True. After that, the If pass, even if IsLoaded return True. – Filimindji Mar 12 '12 at 16:13
  • Are you sure that it isn't a visibility problem, i.e. is the m_BIsLoaded field only ever accessed/modified by the same thread? – afrischke Mar 12 '12 at 16:34
  • False is never assigned to m_bIsLoaded or IsLoaded. The only false assignent is in the declaration of m_bIsLoaded. – Filimindji Mar 12 '12 at 16:42
  • 1
    @Filimindji, make sure that binaries are correct (just to be paranoid - you are running it as service, so maybe binaries are old). Add trace statement to constructor and Load methods, log complete call stack and make sure to trace output to file - may show something useful. – Alexei Levenkov Mar 12 '12 at 16:50
  • I juste recompile all my binaries. Same problem here. – Filimindji Mar 12 '12 at 16:58

2 Answers2

0

This may be caused by some kind of race conditions. Are your setter of IsLoaded and getter of DocGedCourrier running in a single thread?

the_joric
  • 11,986
  • 6
  • 36
  • 57
0

Damned.. IsLoaded was initialy set to False, but looking at the value of another property in the debugger caused IsLoaded to pass to True.

Whatever the reason, thank you for your help.

Filimindji
  • 1,453
  • 1
  • 16
  • 23