如何识别、修复、关闭Windows Sidebar小工具中的内存泄漏?

发布于 2024-07-30 02:58:22 字数 1264 浏览 12 评论 0原文

我为 Windows 边栏编写了一个小工具。 这本质上意味着它是一个微型网页,可以连续运行数月。

几周后,容纳第 3 方小工具的 sidebar.exe 进程的内存使用量(工作集)达到数百兆字节。

由于无法识别内存泄漏的来源,我只是假设这是传闻中的 XMLHttpRequest 闭包问题。 尽管就我而言,我不是异步执行的。 所以我猜这只是JAX而不是AJAX。

涉及网络点击的 JavaScript 函数:

function FetchXML(method, url)
{
   var xmlHttp;
   try
   {
      // Firefox, Opera 8.0+, Safari  
      xmlHttp=new XMLHttpRequest();  
   }
   catch (e)
   {  // Internet Explorer  
      try
      {
         xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");    
      }
      catch (e)
       {
         try
         {
            xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");      
         }
         catch (e)
         {
            throw "XMLHttp not supported"
         }
      }
   }

   xmlHttp.open(method, url, false);
   xmlHttp.send(null);  
   if (xmlHttp.status != 200)
   {
      throw "Server returned status code "+xmlHttp.status.toString();
   }

   if (xmlHttp.responseXML.parseError.errorCode != 0)
   {
      throw "Error in returned XML: "+xmlHttp.responseXML.parseError.reason;
   }

   var responseXML = xmlHttp.responseXML;
   xmlHttp = null;
   return responseXML;
}

这看起来是否可能是内存泄漏的根源?


我担心如果没有真正的关闭,我就会回到原点。

i've written a gadget for Windows Sidebar. This essentially means that it is a miniature web-page, that runs for months on end.

After a few weeks the memory usage (working set) of the sidebar.exe process that houses 3rd party gadgets runs into the hundreds of megabytes.

Without a way to identify the source of memory leaks, i simply assume it is the rumored XMLHttpRequest closure problem. Although in my case i'm not doing it asynchronously. So i guess it's just JAX rather than AJAX.

The javascript function involving the web hit:

function FetchXML(method, url)
{
   var xmlHttp;
   try
   {
      // Firefox, Opera 8.0+, Safari  
      xmlHttp=new XMLHttpRequest();  
   }
   catch (e)
   {  // Internet Explorer  
      try
      {
         xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");    
      }
      catch (e)
       {
         try
         {
            xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");      
         }
         catch (e)
         {
            throw "XMLHttp not supported"
         }
      }
   }

   xmlHttp.open(method, url, false);
   xmlHttp.send(null);  
   if (xmlHttp.status != 200)
   {
      throw "Server returned status code "+xmlHttp.status.toString();
   }

   if (xmlHttp.responseXML.parseError.errorCode != 0)
   {
      throw "Error in returned XML: "+xmlHttp.responseXML.parseError.reason;
   }

   var responseXML = xmlHttp.responseXML;
   xmlHttp = null;
   return responseXML;
}

Does this look like it could ever be the source of a memory leak?


i fear that without an actual closure i'm back to square one.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

夜灵血窟げ 2024-08-06 02:58:22

您的问题太老了,不会受到此影响,但对于以后碰巧遇到它的任何人来说...

Windows 7 64位 SP1 引入了 sidebar.exe 内存泄漏(有些人报告 Vista 中也发生了类似的问题)。 此博文 为我工作。

Your question is too old to be affected with this, but for anyone who happens to run across it later...

Windows 7 64bit SP1 introduced a sidebar.exe memory leak (and some people report similar problems were happening in Vista). The suggested workaround in this blog post worked for me.

昔日梦未散 2024-08-06 02:58:22

这是一个有点晚的答案,但我注意到这个问题没有得到答复。 查看您的代码,您正在同步运行并且没有循环引用。 我怀疑这是内存泄漏的根源,它可能位于代码中的其他地方。 我之前在 Windows 桌面小工具中遇到过内存泄漏,我发现的最大的内存泄漏是在向文档动态添加脚本标记时(例如,使用来自 Web 服务的 JSON 回调方法时)。

顺便说一句,您正在运行的浏览器检查几乎完全是多余的。 IE7 是 Vista 上允许的最低 IE 版本,引入了 XMLHttpRequest() 对象(尽管用户或系统管理员可以禁用它)。 我建议仅使用以下单行来替换它:

xmlHttp = window.XMLHttpRequest ? new XMLHttpRequest() : new ActiveXObject("Microsoft.XMLHTTP");


Two years later, I get an up vote here and rediscover the question and the answer occurs to me straight away. I remembered seeing the following warning on the MDN tutorial for XMLHttpRequest:

注意:您不应该使用同步 XMLHttpRequest,因为由于网络固有的异步特性,使用同步请求时内存和事件可能会通过多种方式泄漏。

我正在努力找出这是否属实,或者只是由某个随机的人添加来帮助散布恐惧(毕竟这是一个维基),但这也许就是您内存泄漏的解释。

This is a bit of a late answer but I noticed this had gone unanswered. Looking at your code, you're running synchronously and there are no circular references. I doubt that is the source of the memory leak and it's likely to be somewhere else in your code. I've come across memory leaks in Windows Desktop Gadgets before and the biggest one I've found is when dynamically adding script tags to the document (for instance, when using JSON callback methods from a web service).

Incidentally, the browser checks you're running are almost completely redundant. IE7, the lowest version of IE allowable on Vista, introduced the XMLHttpRequest() object (although it can be disabled by a user or system administrator). I would recommend just using the following single line to replace it:

xmlHttp = window.XMLHttpRequest ? new XMLHttpRequest() : new ActiveXObject("Microsoft.XMLHTTP");


Two years later, I get an up vote here and rediscover the question and the answer occurs to me straight away. I remembered seeing the following warning on the MDN tutorial for XMLHttpRequest:

Note: You shouldn't use synchronous XMLHttpRequests because, due to the inherently asynchronous nature of networking, there are various ways memory and events can leak when using synchronous requests.

I'm struggling a little to find out if this is true or just added by some random person to aid fear mongering (it is a wiki, after all), but perhaps this is the explanation for your memory leak.

爱情眠于流年 2024-08-06 02:58:22

此外,DOM 对象和 JavaScript 对象位于不同的内存空间中,因此,如果您有像

  table = [];
  table[0] = document.getElementById('myDiv');
  table[0].ownerTable = table;

这样的循环引用,那么数组和 div 都不会被垃圾回收,即使对这两个对象的所有其他引用都已超出范围。

Also, DOM objects and JavaScript objects live in different memory spaces, so if you have circular references like

  table = [];
  table[0] = document.getElementById('myDiv');
  table[0].ownerTable = table;

then neither the array nor the div will ever get garbage collected, even if all other references to the two objects have gone out of scope.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文