log(0) causing a crash on one particular windows XP (SP3) machine
in [Win32 Kernel]
|
Prev: Determining 'transient' nature of file
Next: SmartCard removal monitoring in GINA under Terminal Services / Citrix
From: Rahul on 17 Apr 2010 07:16 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 17 Apr 2010 07:32 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 17 Apr 2010 08:14 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 17 Apr 2010 09:22 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 17 Apr 2010 10:21
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/ |