I have the code below on a social network site, it loads a file that shows users new notification messages if they exist.
Problem is when I leave the page open for a while, it eventually consumes too much memory on my PC and starts to make firefox non-responsive and throws an error message saying that memory is getting low and asking if I should abort the script or something along those line.
Is there a way to do what I have it doing but without using up so much memory over time?
<script type='text/javascript'>
$(document).ready(function(){
var updatenotification = function(){
$('#notificationcontainer')
.load('http://localhost/member/beta_new/notifications.inc.php')
.fadeIn("slow");
};
var auto_refresh = setInterval(function(){updatenotification();}, 60000);
updatenotification();
});
</script>
What exactly do you return. I'll assume it is a large ish dom fragment. You could change the code to just return a small json string, check if there is a valid new notification and then write some markup into the div rather than reloading it each time regardless if there are new notifications. Can you maybe show the markup that you are returning.
I am making a few too many assumptions without knowing exactly what your returning. If it is just a tiny html fragement I cant really see the issue. The script looks ok and should not be causing the issues you speak about.
Also remember that firebug does have big issues at the moment. There are some pretty nasty leaky bugs that cause the memory warning dialog when browsing heavyish ajax/js sites like StackOverflow, Netvibes. Your average user (I assume!) will not have firebug so will not see anything
Related
I have a simple Flask+SQLite app that lives on Digital Ocean droplet and is served by uWSGI (I'll add NGINX when I this issue is solved).
Every time that I load a page, some images fail to load the first time. It's totally random which images and when they fail to load. To overcome this issue, I've made a reloader function that detects the failed images and reload them until they're loaded.
That produces network log like this one:
You can see that for example, icon_order_history.svg failed to load twice, and then successfully loaded the third time.
It's actually all fine if images don't load, I don't really mind it that much, but sometimes css fails to load and results in a situation like this one:
I don't know what could cause this, I don't think it's a bad internet connection since it also happens on localhost.
Here's the reloader function:
function imageRetry(e) {
setTimeout(reloadImg, 1000, e);
}
function reloadImg(e) {
var source = e.src;
e.src = source;
}
Any help is welcome, also feel free to ask me any questions/request more info.
TIA
After not being able to solve the issue for a couple of days. I've decided to redeploy everything using a slightly different method.
That solved the issue but the reason behind slow/random load fails stays unknown.
I'm experiencing a huge memory increase when I'm doing a duration test with navigation between our webpages in our webapplication.
It's not a single-page-application, so I'm navigating with:
window.location.href = "linkToOtherPage.html";
This should clear all used memory right? What I notice in Chrome, is that then type=renderer process (the tab in Chrome) claims way too much memory. When navigating once each 2 seconds, it will eat 1000MB overnight. (Starts at 30MB).
Analyzing the js heap will result in a size of 4-5MB, so it's not in the JS-heap.
Is it so that a memory-leak caused in JS/DOM will keep on living till you close the browser? I would've thought it would be cleared when you navigate to another page.
I didn't quite understand the situation but maybe this is useful:
window.location.href actually loads the page from the cache and maybe if you are referring to the same page over and over again and if the audio src is going to be changed through ajax request maybe you are having all the data saved to the cache?! window.location.reload(true) actually does the trick on getting the data again all from the server.
I'm not sure if I helped you in any way. But if not, sorry for the disappointment! ;D
We have a big single page application, that started to crash from time to time. We were trying to debug it for a while now, but unfortunately, still no results. We used traditional debugging tools, but they were not very useful - perhaps not used correctly.
The app seems to crash most often on Safari, it doesn't crash that often in Chrome, but it still does, so I can't rule out a problem with browser(s).
I have managed to get this crash report, which you can find at the end of this question, unfortunately I don't know what to look for in it. I know it's huge and I'm just throwing it at you saying "here, find a bug", but could you possibly have a look at it and give me some hint what might be wrong or what should I focus on in the report?
Here is the crash report http://pastebin.com/bNxpuS6T
Thanks
What I can see from the crash report and the source code is that your JavaScript code was trying to destroy some DOM objects while still iterating through those, which is the reason of the crash.
I guess you may want to check if any timer associated with the idle tabs is still active.
DETAILS:
The WebKit crashed at
1 com.apple.WebCore 0x00007fff83cace2d WebCore::ScriptExecutionContext::willDestroyActiveDOMObject(WebCore::ActiveDOMObject*) + 45
where the source code is (click here)
void ScriptExecutionContext::willDestroyActiveDOMObject(ActiveDOMObject* object)
{
ASSERT(object);
if (m_iteratingActiveDOMObjects)
CRASH();
m_activeDOMObjects.remove(object);
}
OK this is an odd error, as it's the first ajax page without any complete reloads I'm creating it's an error I never had to face before... and even the Internet doesn't help me - as it doesn't seem to be an usual problem.
Let's get to the Problem step by step:
I have a page where the Ajax request is triggered by a function which simplified looks like this:
$("a[rel='tab']").live('click',function(e) {
pageurl = $(this).attr('href');
$.ajax({url:pageurl+'?rel=tab',success: function(data){
$('#content').html(data);
}});
if(pageurl!=window.location){
window.history.pushState({path:pageurl},'',pageurl);
}
e.preventDefault();
return false;
});
This is parsed by the PHP File and if the property is set the design won't be loaded but instead just the file itself gets loaded - easy hu?
OK, now the problem itself - it was obvious that the page became slower with the time but I didn't really bother at first as I thought it was some mistake in the designs javascripts - but it wasn't.
So I took a look at the firebug and what I've seen explained a lot -> The Requests stack up with every new page! Of course that would lead into an overkill... Well at first I thought it were just the "setInterval"'s and got a workaround running which resets them on each reload.
But that wasn't the only case they also seem to stack up in "scripts" as I don't think that's a plain history as just the reloaded scripts show up more than once!
Any hints in the right would be really helpfull as I am pretty much stuck here!
OK as it seems the issue is just related to the setInterval after all - After trying around for a while I came to the conclusion that this was the main problem, and it was just some kind of a loop in firebug itself.
However maybe someone gets stuck on the same issue so the solution is pretty much this way:
You have to:
1. Create an array where to store your Intervals
2. call your setIntervals this way
3. Reset them on each "new window"
var intervalArr = new Array();
function killIntervals(){
while(intervalArr.length > 0)
clearInterval(intervalArr.pop());
};
These are the array and the function
So these should be added in your AJAX Request function:
killIntervals();
intervalArr.push(setInterval (yourintervalfunction, 5000));
I hope this will come in handy for someone.
I have some code that generates URLs to be used in various places across a site (image src, link hrefs, etc). I am seeing lines in the access logs which show some of the javascript code that generates the URLs masquerading as a file request.
For example, "/this.getIconSrc()" is one that I'm seeing quite a bit. I can't figure out how or why this is occurring and I can't manage to reproduce it without actually entering "http://whateverthesiteis.com/this.getIconSrc()" into the location bar. In most cases, these functions are chained together to generate a URL but the whole function chain does not appear in the server logs, just part of it.
I've probably invested around 30 hours trying to figure out why this is happening but cannot. It doesn't appear to be a browser issue as I've tried in IE 6/7, FF 2/3, Opera, Safari 3, and the problem does not occur. Has anyone else experienced something similar and, if so, what was the solution?
There's three possibilities really:
A bug in your HTML - malformed HTML causing onclick to leak into href, for example
A bug in your Javascript - myIcon.src = 'this.getIconSrc()'; - note the quotes that shouldn't be there
A poorly-written spider is hitting your site (like #Diodeus said: ___)
Edit:
Check the User Agent and Referrer in your logs - they may offer a clue.
Are you generating JavaScript calls like this? This may explain it.
___
#RoBorg... I'm thinking the most likely scenario is #3 since this particular function is actually only called in one place...
function whatever(){
var src = this.getIconSrc();
return src.replace( /((?:https?:\/\/)?(?:[^\/]+\/)*)[^\/]+/, '$1newimage.png' );
}