Comment identifier, réparer, fermer la fuite de mémoire dans le gadget Windows Sidebar?

Question

J'ai écrit un gadget pour Windows Sidebar. Cela signifie essentiellement que c'est une page web miniature, qui dure des mois. Après quelques semaines, l'utilisation de la mémoire (jeu de travail) du processus sidebar.exe hébergeant des gadgets tiers s'exécute en centaines de mégaoctets. Sans un moyen d'identifier la source des fuites de mémoire, je suppose simplement qu'il s'agit du problème de fermeture XMLHttpRequest. Bien que dans mon cas, je ne le fais pas de manière asynchrone. Donc, je suppose que c'est juste JAX plutôt que A JAX.

La fonction javascript impliquant le 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; 
} 

Est-ce que ça ressemble pourrait jamais être la source d'une fuite de mémoire?

---

Je crains que sans une fermeture réelle je suis de retour à la case départ.

Answer 1

Ceci est un peu une réponse tardive mais j'ai remarqué que c'était resté sans réponse. En regardant votre code, vous courez de manière synchrone et il n'y a pas de références circulaires. Je doute que c'est la source de la fuite de mémoire et il est susceptible d'être ailleurs dans votre code. J'ai rencontré des fuites de mémoire dans Windows Desktop Gadgets avant et le plus grand que j'ai trouvé est en ajoutant dynamiquement des balises de script au document (par exemple, en utilisant des méthodes de rappel JSON d'un service Web). Par ailleurs, les vérifications du navigateur que vous exécutez sont presque entièrement redondantes. IE7, la version la plus basse d'IE autorisée sur Vista, a introduit l'objet XMLHttpRequest() (bien qu'il puisse être désactivé par un utilisateur ou un administrateur système). Je recommande simplement en utilisant la seule ligne qui suit pour le remplacer:

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

---

Deux ans plus tard, je reçois un vote ici et en redécouvrir la question et la réponse me vient à tout de suite. Je me suis souvenu avoir vu l'avertissement suivant le tutoriel pour XMLHttpRequest MDN:

Note: Vous ne devriez pas utiliser XMLHttpRequests synchrones parce que, en raison de la nature intrinsèquement asynchrone des réseaux, il existe plusieurs façons de mémoire et les événements peuvent fuir lors de l'utilisation de requêtes synchrones.

Je me bats un peu pour savoir si cela est vrai ou tout simplement ajoutée par une personne au hasard pour aider semer la peur (il est un wiki, après tout), mais peut-être cela est l'explication de votre fuite de mémoire .

Answer 2

En outre, des objets DOM et objets JavaScript vivre dans différents espaces de mémoire, donc si vous avez des références circulaires comme

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

alors ni le tableau ni le div ne jamais obtenir les déchets ramassés, même si toutes les autres références à les deux objets sont sortis de la portée.

Answer 3

Votre question est trop ancienne pour être affectée par cela, mais pour toute personne qui se trouve à travers elle plus tard ...

Windows 7 64bit SP1 a introduit une fuite de mémoire sidebar.exe (et certaines personnes signalent des problèmes similaires se produisaient dans Vista). La solution de contournement suggérée dans this blog post a fonctionné pour moi.