导致错误的原因是“无法从释放的脚本执行代码”

时间:2022-06-28 01:23:16

I thought I'd found the solution a while ago (see my blog):

我想我已经找到解决方案了(见我的博客):

If you ever get the JavaScript (or should that be JScript) error "Can't execute code from a freed script" - try moving any meta tags in the head so that they're before your script tags.

如果您曾经得到JavaScript(或者应该是JScript)错误“无法从释放的脚本执行代码”——尝试移动头部中的任何元标记,使它们位于脚本标记之前。

...but based on one of the most recent blog comments, the fix I suggested may not work for everyone. I thought this would be a good one to open up to the * community....

…但是根据最近的一篇博客评论,我建议的修正可能并不适用于所有人。我认为这将是一个好的一个开放*社区....

What causes the error "Can't execute code from a freed script" and what are the solutions/workarounds?

是什么导致了错误“无法从释放的脚本执行代码”,以及解决方案/解决方案是什么?

12 个解决方案

#1


19  

It sounds like you've hit a bug/problem in the way some tags are handled or that you have references to released objects on which you are trying to execute methods.

听起来好像您处理某些标记的方式遇到了bug/问题,或者您试图执行方法的释放对象的引用。

First I'd move any <meta> tags before any <script> tags as suggested here and numerous other places.

首先,我将移动任何 标记,然后在这里和其他许多地方建议的

Then check to see if you have page/security issues discussed here.

然后检查是否在这里讨论了页面/安全问题。

#2


32  

You get this error when you call a function that was created in a window or frame that no longer exists.

当调用在窗口或框架中创建的不再存在的函数时,会出现此错误。

If you don't know in advance if the window still exists, you can do a try/catch to detect it:

如果您事先不知道窗口是否仍然存在,您可以尝试/捕获来检测它:

try
{
  f();
}
catch(e)
{
  if (e.number == -2146823277)
    // f is no longer available
    ...
}

#3


17  

The error is caused when the 'parent' window of script is disposed (ie: closed) but a reference to the script which is still held (such as in another window) is invoked. Even though the 'object' is still alive, the context in which it wants to execute is not.

当脚本的“父”窗口被处理时(即:closed)会导致错误,但是仍然保存的脚本的引用(例如在另一个窗口中)会被调用。即使“对象”仍然是活着的,它想要执行的上下文却不是。

It's somewhat dirty, but it works for my Windows Sidebar Gadget:

它有点脏,但它适用于我的Windows工具条:

Here is the general idea: The 'main' window sets up a function which will eval'uate some code, yup, it's that ugly. Then a 'child' can call this "builder function" (which is /bound to the scope of the main window/) and get back a function which is also bound to the 'main' window. An obvious disadvantage is, of course, that the function being 'rebound' can't closure over the scope it is seemingly defined in... anyway, enough of the gibbering:

这里有一个大致的想法:“main”窗口设置了一个函数,它将eval'uate一些代码,是的,它太丑了。然后,“child”可以调用这个“builder函数”(它是/绑定到主窗口的范围/),并返回一个也绑定到“main”窗口的函数。当然,一个明显的缺点是,“反弹”函数不能超出它在……中定义的范围。不管怎样,不要再喋喋不休了:

This is partially pseudo-code, but I use a variant of it on a Windows Sidebar Gadget (I keep saying this because Sidebar Gadgets run in "unrestricted zone 0", which may -- or may not -- change the scenario greatly.)

这是部分伪代码,但我在Windows边栏小工具上使用了它的变体(我一直这么说,因为边栏小工具运行在“不受限制的0区”,这可能——也可能不会——极大地改变了场景。)


// This has to be setup from the main window, not a child/etc!
mainWindow.functionBuilder = function (func, args) {
  // trim the name, if any
  var funcStr = ("" + func).replace(/^function\s+[^\s(]+\s*\(/, "function (")
  try {
    var rebuilt
    eval("rebuilt = (" + funcStr + ")")
    return rebuilt(args)
  } catch (e) {
    alert("oops! " + e.message)
  }
}

// then in the child, as an example
// as stated above, even though function (args) looks like it's 
// a closure in the child scope, IT IS NOT. There you go :)
var x = {blerg: 2}
functionInMainWindowContenxt = mainWindow.functionBuilder(function (args) {
  // in here args is in the bound scope -- have at the child objects! :-/
  function fn (blah) {
    return blah * args.blerg
  }
  return fn
}, x)

x.blerg = 7
functionInMainWindowContext(6) // -> 42 if I did my math right

As a variant, the main window should be able to pass the functionBuilder function to the child window -- as long as the functionBuilder function is defined in the main window context!

作为一种变体,主窗口应该能够将functionBuilder函数传递给子窗口——只要在主窗口上下文中定义了functionBuilder函数!

I feel like I used too many words. YMMV.

我觉得我用的词太多了。YMMV。

#4


8  

If you are trying to access the JS object, the easiest way is to create a copy:

如果您试图访问JS对象,最简单的方法是创建一个副本:

var objectCopy = JSON.parse(JSON.stringify(object));

Hope it'll help.

希望它能有所帮助。

#5


6  

Here's a very specific case in which I've seen this behavior. It is reproducible for me in IE6 and IE7.

这是一个非常具体的例子,我看到过这种行为。它可以在IE6和IE7中复制。

From within an iframe:

在iframe:

window.parent.mySpecialHandler = function() { ...work... }

Then, after reloading the iframe with new content, in the window containing the iframe:

然后,在包含iframe的窗口中,用新的内容重新加载iframe后:

window.mySpecialHandler();

This call fails with "Can't execute code from a freed script" because mySpecialHandler was defined in a context (the iframe's original DOM) that no longer exits. (Reloading the iframe destroyed this context.)

由于mySpecialHandler是在一个不再存在的上下文(iframe的原始DOM)中定义的,所以在“无法从已释放的脚本执行代码”时调用失败。(重新加载iframe会破坏这个上下文。)

You can however safely set "serializeable" values (primitives, object graphs that don't reference functions directly) in the parent window. If you really need a separate window (in my case, an iframe) to specify some work to a remote window, you can pass the work as a String and "eval" it in the receiver. Be careful with this, it generally doesn't make for a clean or secure implementation.

但是,您可以在父窗口中安全地设置“serializeable”值(原语、不直接引用函数的对象图)。如果您确实需要一个单独的窗口(在我的例子中是iframe)来为远程窗口指定一些工作,您可以将工作作为字符串传递,并在接收者中“eval”它。注意这一点,它通常不会带来干净或安全的实现。

#6


5  

Beginning in IE9 we began receiving this error when calling .getTime() on a Date object stored in an Array within another Object. The solution was to make sure it was a Date before calling Date methods:

从IE9开始,当在存储在另一个对象的数组中的日期对象上调用. gettime()时,我们就开始接收这个错误。解决方案是在调用Date方法之前确保它是一个日期:

Fail: rowTime = wl.rowData[a][12].getTime()

失败:rowTime = wl.rowData[a][12].getTime()

Pass: rowTime = new Date(wl.rowData[a][12]).getTime()

Pass: rowTime = new Date(wl.rowData[a][12]).getTime()

#7


3  

This error can occur in MSIE when a child window tries to communicate with a parent window which is no longer open.

当子窗口试图与不再打开的父窗口通信时,MSIE中可能会出现此错误。

(Not exactly the most helpful error message text in the world.)

(这并不是世界上最有用的错误信息。)

#8


2  

I ran into this problem when inside of a child frame I added a reference type to the top level window and attempted to access it after the child window reloaded

当我在子框架中向顶层窗口添加引用类型并试图在子窗口重新加载后访问它时,我遇到了这个问题

i.e.

即。

// set the value on first load
window.top.timestamp = new Date();

// after frame reloads, try to access the value
if(window.top.timestamp) // <--- Raises exception
...

I was able to resolve the issue by using only primitive types

我只能使用基本类型来解决这个问题。

// set the value on first load
window.top.timestamp = Number(new Date());

#9


1  

This isn't really an answer, but more an example of where this precisely happens.

这并不是一个真正的答案,而是一个确切发生的例子。

We have frame A and frame B (this wasn't my idea, but I have to live with it). Frame A never changes, Frame B changes constantly. We cannot apply code changes directly into frame A, so (per the vendor's instructions) we can only run JavaScript in frame B - the exact frame that keeps changing.

我们有坐标系A和坐标系B(这不是我的想法,但我必须接受它)。框架永远不变,框架B不断变化。我们不能直接将代码更改应用到框架A中,因此(根据供应商的指示)我们只能在框架B中运行JavaScript——这正是不断变化的框架。

We have a piece of JavaScript that needs to run every 5 seconds, so the JavaScript in frame B create a new script tag and inserts into into the head section of frame B. The setInterval exists in this new scripts (the one injected), as well as the function to invoke. Even though the injected JavaScript is technically loaded by frame A (since it now contains the script tag), once frame B changes, the function is no longer accessible by the setInterval.

我们有一段JavaScript代码,每5秒,需要运行的JavaScript框架B创建一个新的脚本标签和插入的标题部分B帧setInterval存在在这个新的脚本(注射),以及要调用的函数。尽管从技术上讲,注入的JavaScript是由框架A加载的(因为它现在包含了脚本标记),但是一旦框架B发生变化,setInterval就不再访问这个函数。

#10


0  

I got this error in IE9 within a page that eventually opens an iFrame. As long as the iFrame wasn't open, I could use localStorage. Once the iFrame was opened and closed, I wasn't able to use the localStorage anymore because of this error. To fix it, I had to add this code to in the Javascript that was inside the iFrame and also using the localStorage.

我在IE9中得到了这个错误最终打开了一个iFrame。只要iFrame没有打开,我就可以使用localStorage。一旦iFrame被打开和关闭,我就不能再使用localStorage了,因为这个错误。为了修复它,我必须在iFrame内的Javascript中添加这段代码,并使用localStorage。

if (window.parent) {
    localStorage = window.parent.localStorage;
}

#11


0  

got this error in DHTMLX while opening a dialogue & parent id or current window id not found

在打开对话和父id或未找到当前窗口id时,在DHTMLX中获得此错误

        $(document).ready(function () {

            if (parent.dxWindowMngr == undefined) return;
            DhtmlxJS.GetCurrentWindow('wnManageConDlg').show();

});

Just make sure you are sending correct curr/parent window id while opening a dialogue

只要确保在打开对话框时发送正确的curr/父窗口id。

#12


0  

On update of iframe's src i am getting that error.

在更新iframe的src时,我得到了这个错误。

Got that error by accessing an event(click in my case) of an element in the main window like this (calling the main/outmost window directly):

通过访问主窗口中元素的事件(在我的例子中是单击)获得这个错误(直接调用main/outmost窗口):

top.$("#settings").on("click",function(){
    $("#settings_modal").modal("show");
}); 

I just changed it like this and it works fine (calling the parent of the parent of the iframe window):

我只是像这样修改它,它工作得很好(调用iframe窗口父窗口的父窗口):

$('#settings', window.parent.parent.document).on("click",function(){                    
   $("#settings_modal").modal("show");      
});

My iframe containing the modal is also inside another iframe.

包含模态的iframe也在另一个iframe中。

#1


19  

It sounds like you've hit a bug/problem in the way some tags are handled or that you have references to released objects on which you are trying to execute methods.

听起来好像您处理某些标记的方式遇到了bug/问题,或者您试图执行方法的释放对象的引用。

First I'd move any <meta> tags before any <script> tags as suggested here and numerous other places.

首先,我将移动任何 标记,然后在这里和其他许多地方建议的

Then check to see if you have page/security issues discussed here.

然后检查是否在这里讨论了页面/安全问题。

#2


32  

You get this error when you call a function that was created in a window or frame that no longer exists.

当调用在窗口或框架中创建的不再存在的函数时,会出现此错误。

If you don't know in advance if the window still exists, you can do a try/catch to detect it:

如果您事先不知道窗口是否仍然存在,您可以尝试/捕获来检测它:

try
{
  f();
}
catch(e)
{
  if (e.number == -2146823277)
    // f is no longer available
    ...
}

#3


17  

The error is caused when the 'parent' window of script is disposed (ie: closed) but a reference to the script which is still held (such as in another window) is invoked. Even though the 'object' is still alive, the context in which it wants to execute is not.

当脚本的“父”窗口被处理时(即:closed)会导致错误,但是仍然保存的脚本的引用(例如在另一个窗口中)会被调用。即使“对象”仍然是活着的,它想要执行的上下文却不是。

It's somewhat dirty, but it works for my Windows Sidebar Gadget:

它有点脏,但它适用于我的Windows工具条:

Here is the general idea: The 'main' window sets up a function which will eval'uate some code, yup, it's that ugly. Then a 'child' can call this "builder function" (which is /bound to the scope of the main window/) and get back a function which is also bound to the 'main' window. An obvious disadvantage is, of course, that the function being 'rebound' can't closure over the scope it is seemingly defined in... anyway, enough of the gibbering:

这里有一个大致的想法:“main”窗口设置了一个函数,它将eval'uate一些代码,是的,它太丑了。然后,“child”可以调用这个“builder函数”(它是/绑定到主窗口的范围/),并返回一个也绑定到“main”窗口的函数。当然,一个明显的缺点是,“反弹”函数不能超出它在……中定义的范围。不管怎样,不要再喋喋不休了:

This is partially pseudo-code, but I use a variant of it on a Windows Sidebar Gadget (I keep saying this because Sidebar Gadgets run in "unrestricted zone 0", which may -- or may not -- change the scenario greatly.)

这是部分伪代码,但我在Windows边栏小工具上使用了它的变体(我一直这么说,因为边栏小工具运行在“不受限制的0区”,这可能——也可能不会——极大地改变了场景。)


// This has to be setup from the main window, not a child/etc!
mainWindow.functionBuilder = function (func, args) {
  // trim the name, if any
  var funcStr = ("" + func).replace(/^function\s+[^\s(]+\s*\(/, "function (")
  try {
    var rebuilt
    eval("rebuilt = (" + funcStr + ")")
    return rebuilt(args)
  } catch (e) {
    alert("oops! " + e.message)
  }
}

// then in the child, as an example
// as stated above, even though function (args) looks like it's 
// a closure in the child scope, IT IS NOT. There you go :)
var x = {blerg: 2}
functionInMainWindowContenxt = mainWindow.functionBuilder(function (args) {
  // in here args is in the bound scope -- have at the child objects! :-/
  function fn (blah) {
    return blah * args.blerg
  }
  return fn
}, x)

x.blerg = 7
functionInMainWindowContext(6) // -> 42 if I did my math right

As a variant, the main window should be able to pass the functionBuilder function to the child window -- as long as the functionBuilder function is defined in the main window context!

作为一种变体,主窗口应该能够将functionBuilder函数传递给子窗口——只要在主窗口上下文中定义了functionBuilder函数!

I feel like I used too many words. YMMV.

我觉得我用的词太多了。YMMV。

#4


8  

If you are trying to access the JS object, the easiest way is to create a copy:

如果您试图访问JS对象,最简单的方法是创建一个副本:

var objectCopy = JSON.parse(JSON.stringify(object));

Hope it'll help.

希望它能有所帮助。

#5


6  

Here's a very specific case in which I've seen this behavior. It is reproducible for me in IE6 and IE7.

这是一个非常具体的例子,我看到过这种行为。它可以在IE6和IE7中复制。

From within an iframe:

在iframe:

window.parent.mySpecialHandler = function() { ...work... }

Then, after reloading the iframe with new content, in the window containing the iframe:

然后,在包含iframe的窗口中,用新的内容重新加载iframe后:

window.mySpecialHandler();

This call fails with "Can't execute code from a freed script" because mySpecialHandler was defined in a context (the iframe's original DOM) that no longer exits. (Reloading the iframe destroyed this context.)

由于mySpecialHandler是在一个不再存在的上下文(iframe的原始DOM)中定义的,所以在“无法从已释放的脚本执行代码”时调用失败。(重新加载iframe会破坏这个上下文。)

You can however safely set "serializeable" values (primitives, object graphs that don't reference functions directly) in the parent window. If you really need a separate window (in my case, an iframe) to specify some work to a remote window, you can pass the work as a String and "eval" it in the receiver. Be careful with this, it generally doesn't make for a clean or secure implementation.

但是,您可以在父窗口中安全地设置“serializeable”值(原语、不直接引用函数的对象图)。如果您确实需要一个单独的窗口(在我的例子中是iframe)来为远程窗口指定一些工作,您可以将工作作为字符串传递,并在接收者中“eval”它。注意这一点,它通常不会带来干净或安全的实现。

#6


5  

Beginning in IE9 we began receiving this error when calling .getTime() on a Date object stored in an Array within another Object. The solution was to make sure it was a Date before calling Date methods:

从IE9开始,当在存储在另一个对象的数组中的日期对象上调用. gettime()时,我们就开始接收这个错误。解决方案是在调用Date方法之前确保它是一个日期:

Fail: rowTime = wl.rowData[a][12].getTime()

失败:rowTime = wl.rowData[a][12].getTime()

Pass: rowTime = new Date(wl.rowData[a][12]).getTime()

Pass: rowTime = new Date(wl.rowData[a][12]).getTime()

#7


3  

This error can occur in MSIE when a child window tries to communicate with a parent window which is no longer open.

当子窗口试图与不再打开的父窗口通信时,MSIE中可能会出现此错误。

(Not exactly the most helpful error message text in the world.)

(这并不是世界上最有用的错误信息。)

#8


2  

I ran into this problem when inside of a child frame I added a reference type to the top level window and attempted to access it after the child window reloaded

当我在子框架中向顶层窗口添加引用类型并试图在子窗口重新加载后访问它时,我遇到了这个问题

i.e.

即。

// set the value on first load
window.top.timestamp = new Date();

// after frame reloads, try to access the value
if(window.top.timestamp) // <--- Raises exception
...

I was able to resolve the issue by using only primitive types

我只能使用基本类型来解决这个问题。

// set the value on first load
window.top.timestamp = Number(new Date());

#9


1  

This isn't really an answer, but more an example of where this precisely happens.

这并不是一个真正的答案,而是一个确切发生的例子。

We have frame A and frame B (this wasn't my idea, but I have to live with it). Frame A never changes, Frame B changes constantly. We cannot apply code changes directly into frame A, so (per the vendor's instructions) we can only run JavaScript in frame B - the exact frame that keeps changing.

我们有坐标系A和坐标系B(这不是我的想法,但我必须接受它)。框架永远不变,框架B不断变化。我们不能直接将代码更改应用到框架A中,因此(根据供应商的指示)我们只能在框架B中运行JavaScript——这正是不断变化的框架。

We have a piece of JavaScript that needs to run every 5 seconds, so the JavaScript in frame B create a new script tag and inserts into into the head section of frame B. The setInterval exists in this new scripts (the one injected), as well as the function to invoke. Even though the injected JavaScript is technically loaded by frame A (since it now contains the script tag), once frame B changes, the function is no longer accessible by the setInterval.

我们有一段JavaScript代码,每5秒,需要运行的JavaScript框架B创建一个新的脚本标签和插入的标题部分B帧setInterval存在在这个新的脚本(注射),以及要调用的函数。尽管从技术上讲,注入的JavaScript是由框架A加载的(因为它现在包含了脚本标记),但是一旦框架B发生变化,setInterval就不再访问这个函数。

#10


0  

I got this error in IE9 within a page that eventually opens an iFrame. As long as the iFrame wasn't open, I could use localStorage. Once the iFrame was opened and closed, I wasn't able to use the localStorage anymore because of this error. To fix it, I had to add this code to in the Javascript that was inside the iFrame and also using the localStorage.

我在IE9中得到了这个错误最终打开了一个iFrame。只要iFrame没有打开,我就可以使用localStorage。一旦iFrame被打开和关闭,我就不能再使用localStorage了,因为这个错误。为了修复它,我必须在iFrame内的Javascript中添加这段代码,并使用localStorage。

if (window.parent) {
    localStorage = window.parent.localStorage;
}

#11


0  

got this error in DHTMLX while opening a dialogue & parent id or current window id not found

在打开对话和父id或未找到当前窗口id时,在DHTMLX中获得此错误

        $(document).ready(function () {

            if (parent.dxWindowMngr == undefined) return;
            DhtmlxJS.GetCurrentWindow('wnManageConDlg').show();

});

Just make sure you are sending correct curr/parent window id while opening a dialogue

只要确保在打开对话框时发送正确的curr/父窗口id。

#12


0  

On update of iframe's src i am getting that error.

在更新iframe的src时,我得到了这个错误。

Got that error by accessing an event(click in my case) of an element in the main window like this (calling the main/outmost window directly):

通过访问主窗口中元素的事件(在我的例子中是单击)获得这个错误(直接调用main/outmost窗口):

top.$("#settings").on("click",function(){
    $("#settings_modal").modal("show");
}); 

I just changed it like this and it works fine (calling the parent of the parent of the iframe window):

我只是像这样修改它,它工作得很好(调用iframe窗口父窗口的父窗口):

$('#settings', window.parent.parent.document).on("click",function(){                    
   $("#settings_modal").modal("show");      
});

My iframe containing the modal is also inside another iframe.

包含模态的iframe也在另一个iframe中。