Extremely wierd problem I just cannot explain...works in debug, does not work in release.

[Stephan Rose]

In the following section of code:

if(addr == address)
{
this.cache.Add(entry);
return entry.Name;
}

Looks pretty easy and simple. Problem though is, the return entry.Name
line is only sporadically executed even though it is impossible for an
address match to not occur since I know for a fact the necessary data
is there for it to occur.

What happens instead, the function executes the exception at the end
that happens if it never found an address match.

This ONLY happens in Release mode though!
In Debug mode, everything runs just fine...

To make things wierder, the following code works fine in release mode:

if(addr == address)
{
string a = addr.ToString();
string b = address.ToString();
b = a + b;
if (b == "testing234")
{
MessageBox.Show("blah");
}

this.cache.Add(entry);
return entry.Name;
}

Yes, I know it looks stupid. I know it doesn't make sense (at least to
me). But if I add that totally nonesense string code with the if
statement to make sure the compiler doesn't optimize it out, then the
return line is run everytime.

If someone wants to look at the whole function in its entirety, it is
available at http://www.somrek.net/function.cs

I've never seen anything like this happen before and I don't know if I
actually found some issue or if I am just being braindead. =)

Any ideas or thoughts would be much appreciated!

Thanks,

Stephan

 

[Stephan Rose]

If someone wants to look at the whole function in its entirety, it is
available at http://www.somrek.net/function.cs

Looks like my web server doesn't like me putting up .cs files...

So I changed it to http://www.somrek.net/function.txt

 

[Adam Clauss]

float address = entry.Address;
address += (float)entry.Bit/10.0f;
if(addr == address)The thing that catches my eye is that you are testing
equality on floating point values. That is generally a big no no as
floating point values are typically NOT exact.

If you had a "logical" value of 10.0, it might actually come out to
10.0000000001 or somethign along that line. Thus the test for equality
would fail. The better way would be to substract the two and take the
Math.Abs() - see if that value is less than a certain 'tolerance' level
(aka: they are close enough that you know they are actually the same).

 

[Bruce Wood]

I agree with Adam: comparing floats / doubles for equality is a big
no-no.

Furthermore, a float or double should be used to store _only_ measured
quantities for which the concept of error makes sense. For example, you
could use a float or double to store "35.1523mm of rain", because if
you you're going to compare that quantity to something else, a
statement like "within 0.00001mm of yesterday's rainfall" makes sense.

You should never use floats or doubles to represent quantities or
things where precise values matter. The classic example is using them
to store monetary values (a quick road to losing / gaining pennies here
and there). So, I have to wonder exactly what "address" is... I have
the sneaking suspicion that losing a digit on an "address" would be
disastrous....

In cases in which your application can't tolerate precision loss you
should use decimal. If the number of decimal places is fixed then you
may also be able to use int or long and just remember how many decimal
places there are.

 

[Stephan Rose]

I agree with Adam: comparing floats / doubles for equality is a big
no-no.

Furthermore, a float or double should be used to store _only_ measured
quantities for which the concept of error makes sense. For example, you
could use a float or double to store "35.1523mm of rain", because if
you you're going to compare that quantity to something else, a
statement like "within 0.00001mm of yesterday's rainfall" makes sense.

You should never use floats or doubles to represent quantities or
things where precise values matter. The classic example is using them
to store monetary values (a quick road to losing / gaining pennies here
and there). So, I have to wonder exactly what "address" is... I have
the sneaking suspicion that losing a digit on an "address" would be
disastrous....

In cases in which your application can't tolerate precision loss you
should use decimal. If the number of decimal places is fixed then you
may also be able to use int or long and just remember how many decimal
places there are.

Ya know what guys, I didn't even think about that....

I am definitely going to check that tomorrow!

Thanks for the heads up!

--
Stephan
2003 Yamaha R6

kimi no koto omoidasu hi nante nai no wa
kimi no koto wasureta toki ga nai kara