Strange bug: condition true in IF statement, false the next statement

[Guest]

Hi

I'm facing a very strange problem here. My code looks like this

if(A == null
return
doSomethingWith(A.b)

When I run my code (in debug mode), I get a NullReferenceException -- and on breaking, I discover that A is indeed null. (The exception is raised in the doSomethingWith line.

How can this be? No code has been executed between the IF statement and the next statement. In the context I run the code, A *shouldn't* be null, and even if it were - why does it not step into the IF statement and return

What's worse, when I set a breakpoint anywhere near this segment in my code, the problem *disappeaers* -- A isn't null, and everything works properly

This looks like the classic '=' instead of '==' mistake I'm used to from C++, but that's not the case here (I checked, and anyway C# IF statements require bool...). The fact that it disappears on extensive debugging makes me think it's some sort of debugger/runtime-environment bug. I thought it might be related to garbage collection, but that doesn't make sense either (since I have a reference to A, it shouldn't be collected, right?)

Does anyone have any idea what's going wrong

(For completeness' sake, I should mention that the code I'm running was developed for the 1.0 Framework, and I'm now running it with 1.1.)

 

[Guest]

You don't have another thread making changes to A?

 

[Jan Zieschang]

Hi,

we some times have the identical behaviour. It looks like a bug in if-
statement.
I'm realy sure, that there ist no threading issue, because it also
happens to local variables. But i never could reproduce the situation in
sample programs.
It happens on one maschin, but not on another one.

Bye, Jan

 

[Guest]

No, my application is single-threaded; also, unlike the
poster who responded, my bug is deterministic - it *always*
happens, on *every* machine we tried it on...

-----Original Message-----
Hi,

I'm facing a very strange problem here. My code looks like this:

if(A == null)
return;
doSomethingWith(A.b);

When I run my code (in debug mode), I get a

NullReferenceException -- and on breaking, I discover that
A is indeed null. (The exception is raised in the
doSomethingWith line.)

How can this be? No code has been executed between the IF

statement and the next statement. In the context I run the
code, A *shouldn't* be null, and even if it were - why does
it not step into the IF statement and return?

What's worse, when I set a breakpoint anywhere near this

segment in my code, the problem *disappeaers* -- A isn't
null, and everything works properly.

This looks like the classic '=' instead of '==' mistake

I'm used to from C++, but that's not the case here (I
checked, and anyway C# IF statements require bool...). The
fact that it disappears on extensive debugging makes me
think it's some sort of debugger/runtime-environment bug. I
thought it might be related to garbage collection, but
that doesn't make sense either (since I have a reference to
A, it shouldn't be collected, right?).

Does anyone have any idea what's going wrong?

(For completeness' sake, I should mention that the code

I'm running was developed for the 1.0 Framework, and I'm
now running it with 1.1.)

 

[Stu Smith]

Do you have a reproducible bit of code you could post here? eg maybe just
the function called from Main().

I'd be happy to have a look at it if you can post some non-working code.

(Trouble is, it sounds either like a silly mistake of the sort we all make
from time to time, or one of those problems that disappears when you try to
isolate it).

 

[Hatul Shilgy]

Sorry, can't post any code -- but it really is much like the fake snippet I posted.

It's not *my* code, either, or even code developed by my company... it appears in the XtraGrid control, developed by DevExpress.
I just checked, and it doesn't happen in Visual Studio.NET 2002 (I used 2003 before) with framework 1.0, so that settles it as far as I'm concerned -- it's a .NET platform bug.

Do you have a reproducible bit of code you could post here? eg maybe just
the function called from Main().

I'd be happy to have a look at it if you can post some non-working code.

(Trouble is, it sounds either like a silly mistake of the sort we all make
from time to time, or one of those problems that disappears when you try to
isolate it).

___
Newsgroups brought to you courtesy of www.dotnetjohn.com