current community

your communities

more stack exchange communities

Stack Exchange
tour help
stack overflow careers
Take the 2-minute tour ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
up vote 6 down vote favorite
2

With this code:

function baz() {
  var x = "foo";

  function bar() {
    debugger;
  };
  bar();
}
baz();

I get this unexpected result:

enter image description here

When I change the code:

function baz() {
  var x = "foo";

  function bar() {
    x;
    debugger;
  };
  bar();
}

I get the expected result:

enter image description here

Also, if there is any call to eval within the inner function, I can access my variable as I want to do (doesn't matter what I pass to eval).

Meanwhile, Firefox dev tools give the expected behavior in both circumstances.

What's up with Chrome that the debugger behaves less conveniently than Firefox? I have observed this behavior for some time, up to and including Version 41.0.2272.43 beta (64-bit).

Is it that Chrome's javascript engine "flattens" the functions when it can?

Interestingly if I add a second variable that is referenced in the inner function, the x variable is still undefined.

I understand that there are often quirks with scope and variable definition when using an interactive debugger, but it seems to me that based on the language specification there ought to be a "best" solution to these quirks. So I am very curious if this is due to Chrome optimizing further than Firefox. And also whether or not these optimizations can easily be disabled during development (maybe they ought to be disabled when dev tools are open?).

Also, I can reproduce this with breakpoints as well as the debugger statement.

share|improve this question
    
maybe it's getting un-used variables out of your way for you... –  dandavis Feb 7 at 23:09
    
markle976 seems to be saying the debugger; line isn't actually called from inside bar. So look at the stack trace when it pauses in debugger: Is the bar function mentioned in the stacktrace? If I'm right, then the stacktrace should say it's paused at line 5, at line 7, at line 9. –  David Knipe Feb 10 at 0:16
    
I don't think it has anything to do with V8 flattening functions. I think this is just a quirk; I don't know if I'd even call it a bug. I think David's answer below makes the most sense. –  markle976 Feb 10 at 2:44

4 Answers 4

up vote 4 down vote accepted
+50

I've found a v8 issue report which is precisely about what you're asking.

Now, To summarize what is said in that issue report... v8 can store the variables that are local to a function on the stack or in a "context" object which lives on the heap. It will allocate local variables on the stack so long as the function does not contain any inner function that refers to them. It is an optimization. If any inner function refers to a local variable, this variable will be put in a context object (i.e. on the heap instead of on the stack). The case of eval is special: if it is called at all by an inner function, all local variables are put in the context object.

The reason for the context object is that in general you could return an inner function from the outer one and then the stack that existed while the outer function ran won't be available anymore. So anything the inner function accesses has to survive the outer function and live on the heap rather than on the stack.

The debugger cannot inspect those variables that are on the stack. Regarding the problem encountered in debugging, one Project Member says:

The only solution I could think of is that whenever devtools is on, we would deopt all code and recompile with forced context allocation. That would dramatically regress performance with devtools enabled though.

Here's an example of the "if any inner function refers to the variable, put it in a context object". If you run this you'll be able to access x at the debugger statement even though x is only used in the foo function, which is never called!

function baz() {
  var x = "x value";
  var z = "z value";

  function foo () {
    console.log(x);
  }

  function bar() {
    debugger;
  };

  bar();
}
baz();
share|improve this answer
up vote 2 down vote

Wow, really interesting!

As others have mentioned, this seems to be related to scope, but more specifically, related to debugger scope. When injected script is evaluated in the developer tools, it seems to determine a ScopeChain, which results in some quirkiness (since it's bound to the inspector/debugger scope). A variation of what you posted is this:

(EDIT - actually, you mention this in your original question, yikes, my bad!)

function foo() {
  var x = "bat";
  var y = "man";

  function bar() {
    console.log(x); // logs "bat"

    debugger; // Attempting to access "y" throws the following
              // Uncaught ReferenceError: y is not defined
              // However, x is available in the scopeChain. Weird!
  }
  bar();
}
foo();

For the ambitious and/or curious, scope (heh) out the source to see what's going on:

https://github.com/WebKit/webkit/tree/master/Source/JavaScriptCore/inspector https://github.com/WebKit/webkit/tree/master/Source/JavaScriptCore/debugger

share|improve this answer
    
Thanks for the links to the source! –  Gabe Kopley Feb 11 at 1:19
up vote 0 down vote

I suspect this has to do with variable and function hoisting. JavaScript brings all variable and function declarations to the top of the function they are defined in. More info here: http://jamesallardice.com/explaining-function-and-variable-hoisting-in-javascript/

I bet that Chrome is calling the break point with the variable unavailable to the scope because there is nothing else in the function. This seems to work:

function baz() {
  var x = "foo";

  function bar() {
    console.log(x); 
    debugger;
  };
  bar();
}

As does this:

function baz() {
  var x = "foo";

  function bar() {
    debugger;
    console.log(x);     
  };
  bar();
}

Hope this, and / or the link above helps. These are my favorite kind of SO questions, BTW :)

share|improve this answer
    
Thanks! :) I am wondering what FF does differently. From my perspective as a developer, the FF experience is objectively better... –  Gabe Kopley Feb 9 at 18:34
2  
"calling the break point at lex time" I doubt it. That's not what breakpoints are for. And I don't see why the absence of other things in the function should matter. Having said that, if it's anything like nodejs then breakpoints might be very buggy. –  David Knipe Feb 9 at 22:11
up vote 2 down vote

I've also noticed this in nodejs. I believe (and I admit this is only a guess) that when the code is compiled, if x does not appear inside bar, it doesn't make x available inside the scope of bar. This probably makes it slightly more efficient; the problem is someone forgot (or didn't care) that even if there's no x in bar, you might decide to run the debugger and hence still need to access x from inside bar.

share|improve this answer
    
Thanks. Basically I want to be able explain this to javascript beginners better than "The debugger lies." –  Gabe Kopley Feb 9 at 22:22

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.