Internet Explorer 8 is full of surprises. | The Coffeehouse

Xaero_Vincent
Sexy me

OK, the new IE 8 beta is released.

The default standards mode does indeed pass the Acid 2 test.

It also introduces some new hilarious functionality as well :

Get it here.

evildictaitor
if( !succeed( try() ) ) { while(true) try(); }

Yep. It's a null-pointer fault in MSHTML.dll. Hilarious and will get some conspiracy theories going, but basically it's just an OopsieDaisyException thrown in MSHTML.

Xaero_Vincent
Sexy me

Oh I see. So you mean its a known bug in the rendering engine?

evildictaitor
if( !succeed( try() ) ) { while(true) try(); }

Xaero_Vincent wrote:
Oh I see. So you mean its a known bug in the rendering engine?

It's known now. My point was it was unintentional. Copying data from a Null pointer is one of the hazards of programming in C/C++ (hint hint). The IE codebase must be terrible to allow some of these things to go on.

BruceMorgan

evildictaitor wrote:

Xaero_Vincent wrote: Oh I see. So you mean its a known bug in the rendering engine?

It's known now. My point was it was unintentional. Copying data from a Null pointer is one of the hazards of programming in C/C++ (hint hint). The IE codebase must be terrible to allow some of these things to go on.

How do you know it's a null pointer read?

CannotResolveSymbol
{insert caption here}

BruceMorgan wrote:

evildictaitor wrote:

Xaero_Vincent wrote: Oh I see. So you mean its a known bug in the rendering engine?

It's known now. My point was it was unintentional. Copying data from a Null pointer is one of the hazards of programming in C/C++ (hint hint). The IE codebase must be terrible to allow some of these things to go on.
How do you know it's a null pointer read?

Maybe because VS pops up and asks if you'd like to debug, then:

Or because Evildictaitor's got psychic debugging skills Tongue Out

Also, while you're around and we're talking about crashes, any chance that IE could stop trying to reopen the tab after it crashes twice? ACR isn't very useful if I have to kill IE anyways because it keeps on reloading a page that consistently crashes the browser (as it does in this case).

evildictaitor
if( !succeed( try() ) ) { while(true) try(); }

BruceMorgan wrote:

evildictaitor wrote:

Xaero_Vincent wrote: Oh I see. So you mean its a known bug in the rendering engine?

It's known now. My point was it was unintentional. Copying data from a Null pointer is one of the hazards of programming in C/C++ (hint hint). The IE codebase must be terrible to allow some of these things to go on.
How do you know it's a null pointer read?

It's a null pointer fault which you're getting from an argument.

6A7DEB2B push        dword ptr [ebx+14h]
6A7DEB2E call        6A714AEE
6A7DEB33 mov         esi,eax
6A7DEB35 test        esi,esi
6A7DEB37 jne         6A7DEC5F
6A7DEB3D mov         eax,dword ptr [ebp-4]
-> 6A7DEB40 mov         ecx,dword ptr [eax]
6A7DEB42 lea         edx,[ebp-0Ch]
6A7DEB45 push        edx
6A7DEB46 push        6A587848h
6A7DEB4B push        eax

EAX is zero, and the rest of the registers are filled with relocated pointers, which won't be very useful to you.

So basically you're moving a null pointer into ecx from the arguments, i.e you've been given a null argument (the first one) and then when you try and load it's effective address you crash.

Bass
www.spreadfirefox.com/5years/

evildictaitor wrote:

Xaero_Vincent wrote:Oh I see. So you mean its a known bug in the rendering engine?

It's known now. My point was it was unintentional. Copying data from a Null pointer is one of the hazards of programming in C/C++ (hint hint). The IE codebase must be terrible to allow some of these things to go on.

Maybe everyone on the IE team should watch this: http://www.cs.stanford.edu/cslibrary/PointerFunCBig.avi

A couple hundred times for good measure. Expressionless

peterwillcn

yeah...yes..i love the Ie8.....very love ...so love ...cool.....source code..

Shining Arcanine

evildictaitor wrote:

Xaero_Vincent wrote:Oh I see. So you mean its a known bug in the rendering engine?

It's known now. My point was it was unintentional. Copying data from a Null pointer is one of the hazards of programming in C/C++ (hint hint). The IE codebase must be terrible to allow some of these things to go on.

How did professional developers at Microsoft manage to dereference a null pointer? I am an undergraduate student and even I do not make that mistake.

andy_hanger18

Shining Arcanine wrote:
How did professional developers at Microsoft manage to dereference a null pointer? I am an undergraduate student and even I do not make that mistake.

One day, when you're not just a student, writing a big project, in a real job, and you access your first NULL pointer you'll look back at this post and cringe.

esoteric
λ

I'm sure he'll bet his job-to-be on it. Wink

mstefan
Windows SDK coders do it without a .NET

Shining Arcanine wrote:

How did professional developers at Microsoft manage to dereference a null pointer? I am an undergraduate student and even I do not make that mistake.

Just wait until you get out into the real world and start working on large projects. I promise, you'll make more than your share of palm-to-the-forehead, what-was-I-thinking mistakes. Particularly when you're working on complex code that you didn't write. It's the nature of the business, my young padawan.

BruceMorgan

mstefan wrote:

Shining Arcanine wrote:
How did professional developers at Microsoft manage to dereference a null pointer? I am an undergraduate student and even I do not make that mistake.
Just wait until you get out into the real world and start working on large projects. I promise, you'll make more than your share of palm-to-the-forehead, what-was-I-thinking mistakes. Particularly when you're working on complex code that you didn't write. It's the nature of the business, my young padawan.

While that might well be true, only a subset of null pointer dereferences fall into the category of stupid mistakes.

Fixing a null dereference is generally not as trivial as putting a null check ("if (p)") in front of the pointer dereference. That papers over the point of failure but may not address the root cause. And sprinkling many redundant / unnecessary null checks throughout the code can hurt overall performance. We use SAL annotations to guide our tools to identify where a null check is appropriate.

Common root causes include improper error handling code and complex codepaths / ownership chains for objects and data structures which result in lifetime management problems. These are common to any large scale C++ project.

Shining Arcanine

BruceMorgan wrote:

mstefan wrote:

Shining Arcanine wrote:
How did professional developers at Microsoft manage to dereference a null pointer? I am an undergraduate student and even I do not make that mistake.
Just wait until you get out into the real world and start working on large projects. I promise, you'll make more than your share of palm-to-the-forehead, what-was-I-thinking mistakes. Particularly when you're working on complex code that you didn't write. It's the nature of the business, my young padawan.

While that might well be true, only a subset of null pointer dereferences fall into the category of stupid mistakes.

Fixing a null dereference is generally not as trivial as putting a null check ("if (p)") in front of the pointer dereference. That papers over the point of failure but may not address the root cause. And sprinkling many redundant / unnecessary null checks throughout the code can hurt overall performance. We use SAL annotations to guide our tools to identify where a null check is appropriate.

Common root causes include improper error handling code and complex codepaths / ownership chains for objects and data structures which result in lifetime management problems. These are common to any large scale C++ project.

How many lines of code does the typical developer at Microsoft write per day?

Vasudev

Why there are 2 instances of iexplore.exe shown in Task manager when IE8 is run? Anything to do with IE7 emulation ?

BruceMorgan

Vasudev wrote:
Why there are 2 instances of iexplore.exe shown in Task manager when IE8 is run? Anything to do with IE7 emulation ?

That's "Loosely Coupled IE". One is the frame process, one is the tab process. See the white paper here: http://code.msdn.microsoft.com/ie8whitepapers/Release/ProjectReleases.aspx?ReleaseId=565

Vasudev

Thanks Bruce .

"......this isolation will allow improved performance and scalability, and richer ways to recover from failures (including crashes and hangs)."

Nice feature.

mstefan
Windows SDK coders do it without a .NET

BruceMorgan wrote:
And sprinkling many redundant / unnecessary null checks throughout the code can hurt overall performance.

I have a quibble with the "unnecessary" part of that comment. I'm an adherent to defensive programming, where there is no such thing as an "unnecessary" check to make sure you're not dereferencing a null pointer. Certainly I would agree that redundant checks are wasteful, but I've always written code from the perspective that a function should never trust its inputs. A program that performs a few extra instructions to always validate the parameters its passed is preferable to one that doesn't, and crashes.

I'm sure that there's folks that would disagree with this and consider that style of coding to be wasteful, but I've always held to the philopsophy that safety and correctness trumps performance. Of course, you always want your software to run efficiently; but in my experience, shortcuts ("Oh, I don't need to check that pointer being passed to me, I know it'll never be null") always get you in the end, eventually.

BruceMorgan

mstefan wrote:

BruceMorgan wrote:And sprinkling many redundant / unnecessary null checks throughout the code can hurt overall performance.

I have a quibble with the "unnecessary" part of that comment. I'm an adherent to defensive programming, where there is no such thing as an "unnecessary" check to make sure you're not dereferencing a null pointer. Certainly I would agree that redundant checks are wasteful, but I've always written code from the perspective that a function should never trust its inputs. A program that performs a few extra instructions to always validate the parameters its passed is preferable to one that doesn't, and crashes.

I'm sure that there's folks that would disagree with this and consider that style of coding to be wasteful, but I've always held to the philopsophy that safety and correctness trumps performance. Of course, you always want your software to run efficiently; but in my experience, shortcuts ("Oh, I don't need to check that pointer being passed to me, I know it'll never be null") always get you in the end, eventually.

The right answer isn't "never trust your inputs" and it isn't "always trust your inputs". The right answer is "trust you inputs only when you should". Tools like SAL enable us to strictly specify the interface contract for a given function. Code analysis tools like PREfast and PREfix use that specification to identify if callers are breaking that contract. In other words, if you say (with SAL) that function XYZ() has a pointer parameter that should never be NULL, you don't need to null check that parameter. PREfix will identify if any possible codepath could pass a NULL, and flag it. That's why null checks can be unnecessary. We know when a function can trust its inputs.

mstefan
Windows SDK coders do it without a .NET

The problem is, that then you're depending solely (or largely) on analysis tools, rather than defensive coding techniques. And, of course, analysis won't help you at all with exposed APIs. Or to put it another way, if source markup and path analysis were the complete answer, then you wouldn't have programs faulting at all -- and that's obviously not the case. I agree that source analysis tools can help prevent errors like this, but they should be used in conjunction with defensive programming techniques, not instead of it.

BruceMorgan

No, I never said to depend solely (or largely) on analysis tools. I said "trust you inputs only when you should". Your example is one of many examples where you shouldn't.

Functions that expose APIs or any sort of publicly accessible methods obviously fall into the class of functions that can't trust their parameters. Anything with that sort of exposed surface area needs more defensive techniques.

Other types of code don't necessarily need that level of defensive techniques. Private member functions of C++ classes, for example, can safely decide to trust their inputs. If every private member of every class needed to replicate the parameter and error checking of everything in the callstack above it, that adds a lot of redundancy.

If I have code like

if (ptr)
dosomething(ptr)

and it can be demonstrated that every caller of dosomething() has that null check then dosomething() doesn't really need to check that parameter.

If it does decide to check the parameter, then dosomething() has to decide what to do if it is null. Return an error? Should callers handle that error? What would that error be? E_POINTER or some such? A caller has more information about handling such an error. Of course, it's about the same to have

    if (dosomething(ptr) == E_POINTER)
    {
      // handle bad pointer
    }

except you've just handed parameter checking to the callee, which is bad from encapsulation point of view.

At some point, you have to decide that you've done enough parameter validation and get on with actually doing something useful.

Further, if you're using dynamic or static code coverage tools, then multiple redundant levels of checks will obviously demonstrate that you have a lot of unreachable code. This bloats modules and hurts performance. Then you need additional optimization tools to fix that.

I certainly agree with your last sentence. Obviously defining interface contracts with markup and using code analysis tools is only part of the solution - those merely guide you as to where you need checking and where it's redundant.