« The Truth (With Jokes) : Al FrankenV For Vendetta »

Invalid Floating Point Operation in Embedded Internet Explorer

04/18/06

  10:25:51 pm, by Nimble   , 697 words  
Categories: Thoughts, Programming

Invalid Floating Point Operation in Embedded Internet Explorer

Ran across some trouble the other day. We've allowed embedding Internet Explorer windows in our solutions, which is great for linked portals, intro pages, etc. Things were going great guns, but on some particular web pages, things would go into a tailspin. I was tapped on the shoulder to help figure this out, and it turns out to be a bit interesting. I'm posting this so that if anyone else encounters something like this, no, you're not crazy :)

We made a local not-quite-live copy of the web pages in question to test things out. When I ran them, I got an Invalid Floating Point Operation. The call stack said that the error was being thrown in jscript.dll, Microsoft's library for running Javascript (aka ECMA Script).

If you don't know the debugging technique of binary searching, also known as "divide and conquer", and you do debugging, you really must learn. You divide the area to check for bugs in two. You either set a breakpoint before the halfway point, or comment out or remove everything after the halfway point. If you still get the problem, then the problem is in the first half; if you don't, it's in the second half. Pick the half that the problem is in, and divide it in half again.

On to dissecting the problem...

I did binary search debugging on the main HTML page, and discovered that the problem went away if I removed the Javascript include for ows.js.

I looked for the "/_layouts/1033/ows.js" listed in the HTML, and boy, was it a behemoth! More than 300K of just Javascript utility functions, for a total of over 12,000 lines. What to do?

The beauty of binary search debugging is that it works for really large files with less steps than you might figure. I picked line 6,000, found the nearest start of a function, then killed the rest of the file, saved it, tried it, undid my changes, then did the same near line 3,000, and so on, and so on. It still takes a while, but you zero in on it pretty quickly.

I finally found a function which, if I commented it out, everything proceeded normally. The function is called NoptNumParse, and it looks to be a simplistic number parser. Delving further, I found a couple of lines that were causing the trouble:

if (num > 1.79E+308)
  return Number.NaN;

If I commented out these lines, everything proceeded perfectly.

So why would Internet Explorer itself not have any troubles with these?

My best working theory at the moment is that it masks out Invalid Floating Point Operations (more on the Intel floating point architecture here). From what I've read, there are six 'error' conditions that can happen when the processor does math:

  • Underflow - the numbers got too small; they turned into zero
  • Precision - couldn't represent the number exactly in binary (this happens a LOT
  • Denormalized - I must admit, I don't really know what this entails :)
  • Overflow - equivalent to what happens on calculators when they go EEEEEEEEE
  • Divide by zero - a number... was divided by zero
  • Invalid floating point operation - something happened that gives back NaN (not a number), taking the square root of -1 (no, it doesn't do complex numbers for you!), etc.

Delphi, by default, sets the floating point exception mask to ignore the first three, and trip errors on the second set of three.

I did an experiment where I added this to the beginning of the program:

SetExceptionMask(GetExceptionMask+[exInvalidOp]);

...and the web page loads just fine.

At the expense of never catching invalid floating point operations, of course.

It doesn't seem like you can, for example, just set the exception mask, pull up the embedded IE, and set it back. It seems that the embedded IE shares your application's current floating point exception mask, not the one it got when it was created (can someone verify?).

These Javascript pieces are all a standard part of SharePoint applications, from what I can see, so if you're going to handle embedded SharePoint, you might just have to put up with not catching invalid floating point operations.

Hopefully, this will help someone's life be a little less crazy.

3 comments

Comment from: Nick [Visitor]
Nick

Hi Ritchie,
I had the same problem with my app. on winXP, but not on win7. It seems, your solution makes my program to run properly on xp as well. You saved me a lot of time. Great job, thank you!

03/24/11 @ 01:57
Comment from: Nikola [Visitor]
Nikola

You saved me a lot of time too. Nice job :) I would have never found fix for this error.

04/07/11 @ 09:23
Comment from: Peter [Visitor]
Peter

Hi, thanks for this article, you totally saved my day! Our Delphi application had the same problem on XP (not on Win7) and this seems to be THE right fix!

10/04/13 @ 08:50
March 2019
Sun Mon Tue Wed Thu Fri Sat
 << <   > >>
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
Ritchie Annand's blog of everything except sports (...and who knows? I may break that rule some day)

Search

  XML Feeds

powered by b2evolution free blog software