log(0) causing a crash on one particular windows XP (SP3) machine

[Rahul]

Hi All,

we have a VC++ 2008 application (written in C++) which links against
msvcp90.dll. When we run it on win XP (SP3) system and open the file
dialog (internally GetOpenFileName) and select a file in the opened
dialog and do a Ctrl+C then we see msvcp71.dll gets loaded due to Ctrl
+C press.
But on one of our system it does not get loaded and then all most of
the math functions e.g. log start crashing when their argument is 0.
the same functions work fine on all other XP systems with the same
log(0) call.

We suspect there is some library linking issue but are not able to
find which one. We could find only the msvcp71.dll not getting loaded
on the faulty system. Everything else is same.
We also verified that msvcp71.dll and msvcr71.dll exists in c:\windows
\system32. have re-installed all the redistributable packages but the
problem is still happening.

Anybody has any idea about when log(0) call will crash?
Any help is greatly appreciated.

Thanks in advance
Rahul

[Rahul]

Post by Rahul
Hi All,
we have a VC++ 2008 application (written in C++) which links against
msvcp90.dll. When we run it on win XP (SP3) system and open the file
dialog (internally GetOpenFileName) and select a file in the opened
dialog and do a Ctrl+C then we see msvcp71.dll gets loaded due to Ctrl
+C press.
But on one of our system it does not get loaded and then all most of
the math functions e.g. log start crashing when their argument is 0.
the same functions work fine on all other XP systems with the same
log(0) call.
We suspect there is some library linking issue but are not able to
find which one. We could find only the msvcp71.dll not getting loaded
on the faulty system. Everything else is same.
We also verified that msvcp71.dll and msvcr71.dll exists in c:\windows
\system32. have re-installed all the redistributable packages but the
problem is still happening.
Anybody has any idea about when log(0) call will crash?
Any help is greatly appreciated.
Thanks in advance
Rahul

Same thing is happening with divide by 0 (of float values) also, in
all other systems /0 is working well, but on this particular system it
is causing a crash.

[Hector Santos]

Post by Rahul

Post by Rahul
Hi All,
we have a VC++ 2008 application (written in C++) which links against
msvcp90.dll. When we run it on win XP (SP3) system and open the file
dialog (internally GetOpenFileName) and select a file in the opened
dialog and do a Ctrl+C then we see msvcp71.dll gets loaded due to Ctrl
+C press.
But on one of our system it does not get loaded and then all most of
the math functions e.g. log start crashing when their argument is 0.
the same functions work fine on all other XP systems with the same
log(0) call.
We suspect there is some library linking issue but are not able to
find which one. We could find only the msvcp71.dll not getting loaded
on the faulty system. Everything else is same.
We also verified that msvcp71.dll and msvcr71.dll exists in c:\windows
\system32. have re-installed all the redistributable packages but the
problem is still happening.
Anybody has any idea about when log(0) call will crash?
Any help is greatly appreciated.
Thanks in advance
Rahul

Same thing is happening with divide by 0 (of float values) also, in
all other systems /0 is working well, but on this particular system it
is causing a crash.

Divide by zero *is always* an exception - not working well, unless you
specifically checked for it and had an graceful flow from a divide by
zero.

If you had it *working* before, then you should check your logic to
see why it didn't present a problem to you. If you were using a
library that didn't fault, then you, well, just "were lucky" because
that is an always a critical error. But if you are seeing it now,
then its really just a matter the old bug finally caught up to you.

In short, you can't divide by zero. You need to check for that
condition yourself. You can't expect the system to behave correctly
and continue running like its nothing. If you didn't see the problem
before, then all I can say you were "lucky".

Think about it:

X = Y/0

what is the value for X? How do define INFINITY in C/C++?

Only in languages like Javascript and others where there is a specific
"type object" defined infinity. There is no such type or object
type in C/C++. It is undefined and thus you will get undefined behavior.

Do this. Click

START | RUN

and type:

CALC.EXE <enter>

Click VIEW | Scientific and enter ZERO into the calculator. Type
click LOG button. You will see it say:

Invalid Input for function

[Rahul]

Post by Hector Santos

Post by Rahul

Post by Rahul
Hi All,
we have a VC++ 2008 application (written in C++) which links against
msvcp90.dll. When we run it on win XP (SP3) system and open the file
dialog (internally GetOpenFileName) and select a file in the opened
dialog and do a Ctrl+C then we see msvcp71.dll gets loaded due to Ctrl
+C press.
But on one of our system it does not get loaded and then all most of
the math functions e.g. log start crashing when their argument is 0.
the same functions work fine on all other XP systems with the same
log(0) call.
We suspect there is some library linking issue but are not able to
find which one. We could find only the msvcp71.dll not getting loaded
on the faulty system. Everything else is same.
We also verified that msvcp71.dll and msvcr71.dll exists in c:\windows
\system32. have re-installed all the redistributable packages but the
problem is still happening.
Anybody has any idea about when log(0) call will crash?
Any help is greatly appreciated.
Thanks in advance
Rahul

Same thing is happening with divide by 0 (of float values) also, in
all other systems /0 is working well, but on this particular system it
is causing a crash.

Divide by zero *is always* an exception - not working well, unless you
specifically checked for it and had an graceful flow from a divide by
zero.
If you had it *working* before, then you should check your logic to
see why it didn't present a problem to you.  If you were using a
library that didn't fault, then you, well, just "were lucky" because
that is an always a critical error.  But if you are seeing it now,
then its really just a matter the old bug finally caught up to you.
In short, you can't divide by zero.  You need to check for that
condition yourself.  You can't expect the system to behave correctly
and continue running like its nothing.  If you didn't see the problem
before, then all I can say you were "lucky".
    X = Y/0
what is the value for X?  How do define INFINITY in C/C++?
Only in languages like Javascript and others where there is a specific
  "type object" defined infinity.  There is no such type or object
type in C/C++.  It is undefined and thus you will get undefined behavior.
Do this.  Click
    START | RUN
    CALC.EXE <enter>
Click VIEW | Scientific and enter ZERO into the calculator.  Type
   Invalid Input for function
--
HLS

You are right, we should not have divide by zero in the code itself,
But the problem is that its a third party code and we want a quick
fix.
After some search we found that somebody is changing the floating
point flags in between. IF we reset them to have the bit
_SW_ZERODIVIDE set then the divide by zero goes without crash.

But the question is, the flags are getting changed only when we are
doing Ctrl+C (copy action) inside the file open dialog shown by
GetOpenFileName. This looks strange..

[Jochen Kalmbach [MVP]]

Hi Rahul!

Post by Rahul
But the question is, the flags are getting changed only when we are
doing Ctrl+C (copy action) inside the file open dialog shown by
GetOpenFileName. This looks strange..

This is quite "normal"... If you open the "FileOpenDialog", then all
shell extensions get loaded in *your* process... and one of this
extensions seems to change the floating-point control wird ;)

This is a "normal" bug...

[Hector Santos]

Post by Jochen Kalmbach [MVP]
Hi Rahul!

Post by Rahul
But the question is, the flags are getting changed only when we are
doing Ctrl+C (copy action) inside the file open dialog shown by
GetOpenFileName. This looks strange..

This is quite "normal"... If you open the "FileOpenDialog", then all
shell extensions get loaded in *your* process... and one of this
extensions seems to change the floating-point control wird ;)
This is a "normal" bug...

So he needs to reset it after returning from FileOpenDialog()?

Interesting.

[Jochen Kalmbach [MVP]]

Hi Hector!

Post by Hector Santos

Post by Jochen Kalmbach [MVP]
This is a "normal" bug...

So he needs to reset it after returning from FileOpenDialog()?
Interesting.

I have seens many "shell extensions" and other "hook-dlls" which change
the floating point settings.

From my point of view: It is unpossible to detect if the settings where
changed... the design of the floating-point-control word is the main
problem... if there were nothing to change/control, then there would be
no problem...

In general, there is no good rule to prevent changes or to garantee the
correct executing of your floating point opertion except:

// Set MY control word...
// Execute floating point operation...

[Rahul]

Post by Jochen Kalmbach [MVP]
Hi Hector!

Post by Hector Santos

Post by Jochen Kalmbach [MVP]
This is a "normal" bug...

So he needs to reset it after returning from FileOpenDialog()?
Interesting.

I have seens many "shell extensions" and other "hook-dlls" which change
the floating point settings.
 From my point of view: It is unpossible to detect if the settings where
changed... the design of the floating-point-control word is the main
problem... if there were nothing to change/control, then there would be
no problem...
In general, there is no good rule to prevent changes or to garantee the
// Set MY control word...
// Execute floating point operation...
--
Greetings
   Jochen
    My blog about Win32 and .NET
   http://blog.kalmbachnet.de/

Thanks Jochen,
That was very helpful, now we understand the exact reason.
We will try to prevent all dived by zero in the code, to be on the
safer side :-)

Thanks again
Rahul