Error calling VB6 DLL [modified*2]

Shog9 0

Here's the (very much simplified) code that brought a smile to my face today:

void DoTheChecking(double diameter, double rate)
{
   // WheelLib is a pointer to a COM object implemented in VB6
   HRESULT hr = WheelLib->CheckWheel(diameter, rate);
   if (!SUCCEEDED(hr))
      FreakOut();
}

'Thing is, this wonderful little routine has been in use for years without problems. Last week, we started calling it from a new program, and all hell broke loose. The CheckWheel() call failed every time. I figured there had to be something different in how it was being called, so i dropped in a breakpoint and checked the parameters. But, they looked just fine. In fact, the other callers were passing the exact same values and working perfectly. So then i took a look at the new caller:

...
double diameter = 54.5;
double rate = 15000.0;
   double factor = 54.012;
   double cutoff = factor/scale;
   // TODO: do something useful with cutoff

DoTheChecking(diameter, rate);
...

Ah. That's it. ;) Hint #1: scale has the value 0.0 Solution: The FP code that VB generates checks the FP status word periodically, and throws an exception if it indicates an error. It does not, however, clear the status word upon being called from an external source. The div-by-zero bug in the calling code, even though it didn't cause any problems directly, left the _SW_ZERODIVIDE bit set in the status word, and VB picked it up and ran with it. Tucking in a call to _clearfp() in DoTheChecking() took care of things (as did building the VB DLL with FP error-checking disabled).

Last modified: 10hrs 55mins after originally posted -- Added solution

But who is the king of all of these folks?

leppie

I dont get it :sigh: Is it an instance method maybe?

xacc.ide - now with IronScheme support
IronScheme - 1.0 alpha 1 out now

Baconbutty

What is?

I still remember having to write your own code in FORTRAN rather than be a cut and paste merchant being pampered by colour coded Intellisense - ahh proper programming - those were the days :)

Dewm Solo

I fail to see it as well. Except for rate maybe being a too big value? The rest looks fine from where I stand (or sit I should say).

Dewm Solo - Managed C++ Developer

Shog9 0

Nope. There's a reason it took me the better part of the afternoon to figure it out... it is subtle. I've added a pretty good hint now though, one which i had to dig through three files, four classes, and around six methods to actually find originally. ;)

PIEBALDconsult

Shog9 wrote:

Hint: scale has the value 0.0

Soooo... the post's subject isn't operative?

Shog9 0

FP exceptions are masked (as is the default in VC++), and cutoff is never used... ;)

CPallini

Do you mean the VB6 code catches the divide exception? unbelievable! :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke

Shog9 0

Yup... :)

PIEBALDconsult

What's FP?

Shog9 0

Floating-point.

But who is the king of all of these folks?

Brady Kelly

What would something happen if cutoff was used? Would that trigger the previously masked error flag?

Shog9 0

cutoff, as calculated in the problem scenario, is NaN. Since exceptions are masked on the C++ side of things, that value will just propagate through any other calculations it's used in. If i were to pass it into VB after clearing the status word, i suspect it would result in an exception being thrown the first time it was used in a calculation, but i haven't actually tried this. Generally, passing NaN around isn't a particularly useful thing to do anyway; the cutoff calculation would have been a rather unpleasant bug on its own if it had actually been used anywhere.

But who is the king of all of these folks?

Brady Kelly

That's why I like C#. Division by zero is clearly an exception, and cutoff retains it's initial, or prior value. The above is just plain scary. :~

Shog9 0

Brady Kelly wrote:

Division by zero is clearly an exception, and cutoff retains it's initial, or prior value.

If the exception stops the program, or is otherwise caught outside of the scope in which cutoff is relevant, then that's fine (assuming that the program stopping is not itself somehow catastrophic). But, if the program lives, cutoff now has a potentially-undetectably invalid value. There are trade-offs both ways. Of course, i wouldn't write an exception handler to catch division by zero. I'd either check the divisor first, or the quotient afterwards. Exception handling code is both too awkward to write and too heavy to run for tasks such as these. (BTW - if you were to implement the bit of code i wrote in C#, you wouldn't get an exception either. DivideByZeroException is thrown only by integer division, same as in native code. There's just no option to represent infinity in the integer datatypes.)

But who is the king of all of these folks?

Brady Kelly

But wait, there's more! Casting Infinity to an int gives -2147483648. I can see some nasties happening down that little travelled path.