Error calling VB6 DLL [modified*2]
-
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 cutoffDoTheChecking(diameter, rate);
...Ah. That's it. ;) Hint #1:
scalehas the value0.0Solution: 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()inDoTheChecking()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?
-
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 cutoffDoTheChecking(diameter, rate);
...Ah. That's it. ;) Hint #1:
scalehas the value0.0Solution: 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()inDoTheChecking()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?
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 :)
-
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 cutoffDoTheChecking(diameter, rate);
...Ah. That's it. ;) Hint #1:
scalehas the value0.0Solution: 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()inDoTheChecking()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?
-
I dont get it :sigh: Is it an instance method maybe?
xacc.ide - now with IronScheme support
IronScheme - 1.0 alpha 1 out nowNope. 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. ;)
-
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 cutoffDoTheChecking(diameter, rate);
...Ah. That's it. ;) Hint #1:
scalehas the value0.0Solution: 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()inDoTheChecking()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?
Shog9 wrote:
Hint: scale has the value 0.0
Soooo... the post's subject isn't operative?
-
Shog9 wrote:
Hint: scale has the value 0.0
Soooo... the post's subject isn't operative?
-
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 cutoffDoTheChecking(diameter, rate);
...Ah. That's it. ;) Hint #1:
scalehas the value0.0Solution: 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()inDoTheChecking()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?
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 -
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 -
What's FP?
-
What's FP?
-
What would something happen if
cutoffwas used? Would that trigger the previously masked error flag? -
What would something happen if
cutoffwas used? Would that trigger the previously masked error flag?cutoff, as calculated in the problem scenario, isNaN. 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; thecutoffcalculation 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?
-
cutoff, as calculated in the problem scenario, isNaN. 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; thecutoffcalculation 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?
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. :~
-
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. :~
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
cutoffis relevant, then that's fine (assuming that the program stopping is not itself somehow catastrophic). But, if the program lives,cutoffnow 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.DivideByZeroExceptionis 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 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
cutoffis relevant, then that's fine (assuming that the program stopping is not itself somehow catastrophic). But, if the program lives,cutoffnow 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.DivideByZeroExceptionis 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?
But wait, there's more! Casting Infinity to an int gives -2147483648. I can see some nasties happening down that little travelled path.