505001 - Cannot access optimized closure with Firebug active

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect, P2)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1

While running Mozmill tests against the 1.9.1 branch I have detected that we get a similar problem as the one reported in bug 496790 for mootools. Running the given steps will result in the following error in the Error Console and Mozmill never finish running the test:

Error: cannot access optimized closure
Source File: file:///Volumes/data/build/mozmill/trunk/mozmill/extension/resource/modules/frame.js
Line: 381


Collector.prototype.initTestDirectory = function (directory) {
  var r = this;
  function recursiveModuleLoader(dfile) {
    r.loaded_directories.push(directory);
    var dfiles = os.listDirectory(dfile);
    for (i in dfiles) {
      var f = dfiles[i];
      if ( f.isDirectory() && 
           !withs.startsWith(f.leafName, '.') && 
           withs.startsWith(f.leafName, "test") &&
           !arrays.inArray(r.loaded_directories, f.path) ) {
        recursiveModuleLoader(os.getFileForPath(f.path));
      } else if ( withs.startsWith(f.leafName, "test") && 
                  withs.endsWith(f.leafName, ".js")    &&
                  !arrays.inArray(r.test_modules_by_filename, f.path) ) {
        r.initTestModule(f.path);
      }
      r.testing.push(f.path);
=>  }
  }
  recursiveModuleLoader(os.getFileForPath(directory));
}

Steps:
1. Install Mozmill 1.2 in the current profile (http://code.google.com/p/mozmill/)
2. Clone the Mozmill-Test repository (http://hg.mozilla.org/qa/mozmill-tests/)
3. Start Mozmill from the Tools menu
4. Run the test 'firefox/restartTests/testThemeInstallUninstall/test1.js'
5. Restart the Browser
6. Run the test 'firefox/restartTests/testThemeInstallUninstall/test2.js'

With step 6 the test will not be run and the above mentioned error is shown in the Error Console.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: addl. patch

Hg seems to be down at the moment. So I cannot check-in the additionally fix we need to get the tests running due to the latest AMO changes. Please patch your latest hg tip manually for now.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Comment on attachment 389283 [details] [diff] [review]
addl. patch

Hg works again. I was able to push this changeset. So getting the latest version is enough now.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mikeal, do you have another and simpler steps in mind we could do to reproduce this error? I believe there are other situations which could block us from running Mozmill tests. Asking for blocking.

Comment 4

[Samuel Sidler (old account; do not CC)]

I don't see how this can be blocking without a better rationale. Are we sure this even belongs in the JS component? And... is this a Mozilla bug or a Mozmill bug?

Comment 5

[Mikeal Rogers [:mikeal] (mrogers@)]

This code is kind of hairy and I'm not sure exactly what would be causing the error. My guess is the recursion plus the closure is trigger some odd condition.

The fact that it runs the first time and not the second is incredibly odd to me.

I *think* this error is coming from here:

http://mxr.mozilla.org/mozilla-central/source/js/src/jsfun.cpp#564

Why it's happening, no idea what so ever.

Comment 6

[Brendan Eich [:brendan]]

We need an accurate line number -- if line 381 is

=>  }

then something's off. Reduced testcase with accurate line numbers?

/be

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: example test

Mikeal, I don't have any idea what's going on here. This error is raised when a module is included. Somehow it also happens for other tests. Are you able to reproduce it just by running this test?

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Ok, so the problem is located in Firebug. After the push of the last test module to the testing array in frames.js we magically jump into errors.js which is part of Firebug. When Venkman opens this file the closure error is thrown right away. The selected line of code is 118:

    114     // extends consoleListener
    115 
 -  116     observe: function(object)
    117     {
 -  118         try
    119         {
 -  120             if (window.closed)
 -  121                 this.stopObserving();
 -  122             if (!FBTrace)
 -  123                 return;
    124         }

Rob, can the Firebug team have a look at this bug?

Comment 9

[Rob Campbell [:rc] (:robcee)]

I'm not sure how Firebug fits into this. In your initial comment, you say,

(In reply to comment #0)
...
> Steps:
> 1. Install Mozmill 1.2 in the current profile
> (http://code.google.com/p/mozmill/)
> 2. Clone the Mozmill-Test repository (http://hg.mozilla.org/qa/mozmill-tests/)
> 3. Start Mozmill from the Tools menu
> 4. Run the test 'firefox/restartTests/testThemeInstallUninstall/test1.js'
> 5. Restart the Browser
> 6. Run the test 'firefox/restartTests/testThemeInstallUninstall/test2.js'
> 
> With step 6 the test will not be run and the above mentioned error is shown in
> the Error Console.

And yet there's no mention of Firebug. Are you including it in Mozmill?

Based on your code-snippet in comment #8, it looks like you're using the trace-enabled / development versions of Firebug. Which version are you using?

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

No it's not included into Mozmill. While trying to figure out why it happens I have noticed that Firebug is the cause of this problem. I wasn't aware before because Firebug is always running in my profiles.

Here the list of add-ons in my Mozmill profile:

Adblock Plus 1.1
DOM Inspector 2.0.3
Firebug 1.5X.0a17 [DISABLED]
JavaScript Debugger 0.9.87.4 [DISABLED]
MozMill 1.2
Nightly Tester Tools 2.0.2

Comment 11

[Rob Campbell [:rc] (:robcee)]

alright, we can take a look next week, though may have to ping some of you for MozMill setup help.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Thanks Rob. You can ask me at any time. Also see comment 0 for the installation and comment 7 for an example patch. If it will not work for you just send me a mail or contact me on IRC.

Comment 13

[John J. Barton]

Ok I think we have another, possibly better test case from
http://code.google.com/p/fbug/issues/detail?id=2261

The page is specific to this bug and has a long explanation in the page. 
http://code.zemanta.com/fry/firebug.html

I verified that it works with Firebug inactive and fails with Firebug 1.5a20 active in 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

We also fail with Firebug 1.5a22pre in 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090821 Minefield/3.7a1pre

It looks like the message come from the 
   return "works"
line, so the non-existing function error message comes in to jsd.onError, followed by the closure error message.

The Call scope when we stop on line 12 is empty in Firebug, though we don't know for sure if this is because the Call scope has no properties.

I'm only guessing that the result in comment 8 is because the onError runs then later the consoleService gets the event and you see it. But as far as I can tell the problem is in the catch block when Firebug has its hands on jsd.

A simple way to get close to the problem is to set a break point in jsd_xpc.cpp
near line 575
hook->OnError (nsDependentCString(message), fileName, line, pos, flags, errnum, val, &rval);
since we know that is hit before and at the point of error.

Comment 14

[John J. Barton]

We should understand this one before FF 3.6. We see this message fairly often, but always elusive.

Comment 15

[Matthew W]

I'm running into this issue too.

It seems to happen when an exception raised when there's a recursive function call somewhere in the call stack. The exception gets re-raised as the mysterious

"InternalError: cannot access optimized closure"

This is with Firebug 1.4.0b7 and FF 3.5.2

Perhaps this will help you guys track it down: changing the way I define the recursive function in question, seems to make this issue go away. eg changing from

function foo(bar) {... foo(recursively); ...}

to

var foo = function(bar) {... foo(recursively); ...}

Incase it's relevant: my recursive calls aren't tail-recursive.

Comment 16

[Matthew W]

In retrospect: there's a chance that recursion may be a red herring here, although was interested to see that the original example was also a very similar form of recursive function call to mine.

The other thing my example has in common with it, is that they both call a function defined in the local scope using "function foo()" syntax.

Comment 17

[Ernst de Haan]

I just ran into the same issue with Firebug 1.4.2 on Firefox 3.5.2 on Mac OS X 10.5.8. Same for me: my code calls a function defined in the local scope using "function foo()" syntax.

Comment 18

[Damon Sicore (:damons)]

Blocking 1.9.2+, P2, assigning to bkap.

Comment 19

[John J. Barton]

For some reason I am now seeing this error message in Firebug 1.5 svn and Firefox 3.5.3

Open 
http://getfirebug.com/tests/content/script/singleStepping/index.html
and follow the on page instructions. After a long pause:

[JavaScript Error: "cannot access optimized closure" {file: "chrome://browser/content/places/controller.js" line: 1612}]

Comment 20

[Rob Campbell [:rc] (:robcee)]

any news here blake?

Comment 21

[Blake Kaplan (:mrbkap) (inactive)]

I was actually hoping that this would be fixed by the patch for bug 522590 (which is currently fixed in tracemonkey but not yet on mozilla-central).

In trying to verify this, though, I found that I don't have access to the mozmill project on google code, so either someone who can reproduce this will have to try the patch out or give me access to mozmill.

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Blake, the project has been moved to Github. You can download the latest version at http://github.com/mikeal/mozmill/downloads or just go to https://addons.mozilla.org/de/firefox/addon/9018

Comment 23

[Andrey Sidorov]

Attachment: another one test case

Comment 24

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Blake, I can also not reproduce the error with recent builds but the example from John still shows the error with a recent Shiretoko build and Firebug 1.5Xb1 installed.

Comment 25

[John J. Barton]

Not Mac only, happens on windows.

Comment 26

[Blake Kaplan (:mrbkap) (inactive)]

I am clearly doing something wrong ... I can't reproduce this with any of the STR in this bug.

Comment 27

[John J. Barton]

No, I think the problem is that this bug keeps coming and going. (What is STR?)

I don't see it on Firebug 1.4.5 or 1.5b4, but these are also not the versions reported here.

Comment 28

[John J. Barton]

Sorry, specfically the case
http://code.zemanta.com/fry/firebug.html
"works" for me on  
FF 3.5.5 Firebug 1.4.5
FF 3.6b4pre Firebug 1.5b4

Comment 29

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to comment #27)
> No, I think the problem is that this bug keeps coming and going. (What is STR?)

Ah, that makes sense. STR = Steps To Reproduce.

> I don't see it on Firebug 1.4.5 or 1.5b4, but these are also not the versions
> reported here.

Given that and that the freeze is tonight and that it's almost 8pm where I am right now, I don't think this bug is going to get fixed for the freeze. I'm not sure how much of a problem remains here because I've never been able to reproduce it and I don't really understand how widespread it is.

Comment 30

[John J. Barton]

I understand, but when it hits it is very bad. Next time I see it I will work on the test procedure.

Comment 31

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Just an idea... I'm always using the tracing enabled version of Firebug. Could that be the cause? John, do you flip between both versions? That could be the reason why you are seeing that on and off.

Comment 32

[John J. Barton]

Sorry, 1.5 only comes in the tracing version.
 
Does anyone understand places/controller? Is it async? Dependent upon database?

Comment 33

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I'm not able to reproduce it anymore. Whether which Firefox nor Firebug build I use.

Comment 34

[John J. Barton]

I just reproduced this message with Firefox 3.5 using 
http://code.zemanta.com/fry/firebug.html

The message occurs whether or not Firebug is active on the page.

Comment 35

[John J. Barton]

We need someone who understands the possible code paths than produce this message to make some suggestions on why the error comes and goes.

Comment 36

[John J. Barton]

No bug with the same Firebug code on FF 3.6b4.

Comment 37

[Brendan Eich [:brendan]]

Sounds like a bug -- it shouldn't be non-deterministic. Ideas:

1. Bisect changes from 3.5 to 3.6b4 to find what fixed this bug.

2. Find a semi-reproducible, small (js shell, ideally) testcase.

/be

Comment 38

[Henrik Skupin [:whimboo][⌚️UTC+1]]

John, does it mean you can reproduce it with a clean profile and no other add-ons instatlled? I really have a hard time to see that. I always get the "It works" message box.

Comment 39

[Blake Kaplan (:mrbkap) (inactive)]

This was marked blocking- because we can't block on a bug that nobody has solid steps to reproduce.

Comment 40

[zmarties]

Attachment: Minimal testcase that shows this bug every time

This testcase shows the bug for me every time - with Firebug off, the correct "hello world" is output; with Firebug on the closure exception is hit instead

Comment 41

[Brendan Eich [:brendan]]

What's the stack for that exception on that testcase? Thanks,

/be

Comment 42

[John J. Barton]

zmarties which OS and version of Firefox are you running?

If it is FF 3.6, please attach your about:support if you don't mind.

I am not able to reproduce a bug with Firebug 1.5 Firefox 3.6 on linux or Firebug 1.5.1b1 on Firefox 3.5.6 on WinXP.  So I wonder if there is some setting that is involved to explain why this bug goes away when we look for it.

Comment 43

[Blake Kaplan (:mrbkap) (inactive)]

Unassigning from myself since I'm not sure what needs to be done here.

Comment 44

[Olivier Vit (just a reporter)]

(In reply to comment #40)
> Created an attachment (id=427096) [details]
> Minimal testcase that shows this bug every time
> 
> This testcase shows the bug for me every time - with Firebug off, the correct
> "hello world" is output; with Firebug on the closure exception is hit instead

however this code doesn't validate on jslint.com
It would be safer to have a clean JS code for the test case.

Comment 45

[Luke Wagner [:luke]]

This was likely fixed by recent aliasedvar/debug-scope-proxy work.  Feel free to reopen if the problem reproduces.