From: Rahul on
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
From: Rahul on
On Apr 17, 4:16 pm, Rahul <rsharma.ch...(a)gmail.com> wrote:
> 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.
From: Hector Santos on
Rahul wrote:

> On Apr 17, 4:16 pm, Rahul <rsharma.ch...(a)gmail.com> wrote:
>> 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

--
HLS
From: Rahul on
On Apr 17, 5:14 pm, Hector Santos <sant9...(a)nospam.gmail.com> wrote:
> Rahul wrote:
> > On Apr 17, 4:16 pm, Rahul <rsharma.ch...(a)gmail.com> wrote:
> >> 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
>
> --
> 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..

From: Jochen Kalmbach [MVP] on
Hi 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...

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/