This project has moved and is read-only. For the latest updates, please go here.

Large Memory leak when using Linq2IndexedDB api.


I have made a demo html file (unzip and click on testfile.html), when you click the add something button, upto 2MB of memory is allocated and never returns (You can see this in the chrome task manager ..window > taskmanager). I left an app that I built on top of Linq2indexedDB and it had gained 1GB of memory after 2 days of usage that it was unwilling to release.

Could you please look into what is going on.. Hope this is an easy fix!


file attachments


senthil_codeplex wrote Oct 4, 2012 at 11:47 PM

I would like to change the Impact to 'High' on this bug if someone can verify it ofcourse.

(Looks like I can't do that myself as I do not have the necessary privilege level.)

KDegrave wrote Oct 5, 2012 at 6:14 AM


Changed it to High. I'll try to look in to it asap. If you would be able to locate what is causing the memory leak that would be great.

I have a feeling that the problem is my webworker.

Greetings Kristof

KDegrave wrote Oct 5, 2012 at 2:25 PM

found a leak when using web workers. I don't know if this affects your case. Would you like to test the new version? Hope this solves the issue, otherwise I will have to digg deeper :).



senthil_codeplex wrote Oct 5, 2012 at 11:29 PM

Hi Kristof,

Thanks so much for the fix. As of now I do not see the leak in the example I created to file the report. I am going to pull it and use it with my app, and will let you know if the bug is gone for good.

thanks for the swift response!


senthil_codeplex wrote Oct 13, 2012 at 6:44 PM

Unfortunately the bug still seems to be lurking around. Although it is not present in the example I posted to show the bug, when I pulled the latest version from the Downloads tab and used with my app, it is leaking at similar magnitudes (1GB per day). When I disable this library, and I went back to using 38MB or so again(and is constant).

Could you verify if there are web-workers in other places which are not being terminated. Let me know if I can post any other useful information to help you get to the bottom of this.

KDegrave wrote Oct 14, 2012 at 12:25 PM

I think it will be another leak then the webworkers. In my lib I have only a single point where I create and terminate a webworker.

Have you tried making a heap comparison and look which object stays in memory?

senthil_codeplex wrote Oct 15, 2012 at 6:28 AM

"Have you tried making a heap comparison and look which object stays in memory?"

I am relatively new to JS, could you let me know how to do this heap comparison (any tools, techniques). I am running this app on Google Chrome + OSX.

senthil_codeplex wrote Oct 15, 2012 at 6:31 AM

Just discovered this:

Will try it out and post what I find.

senthil_codeplex wrote Oct 16, 2012 at 8:12 AM


The heapcomparison tool generated this view (containment view: ). It shows a bunch of link2indexeddb objects retained in memory(I think). If you have specific instructions for me on what you want to see (that might help you get an idea) please leave me a note.


KDegrave wrote Oct 17, 2012 at 8:33 AM

Can you show me some content of these objects?

I tried accomplish the same thing with my consumptions demo, but I don't see those object appear. Maybe there is something wrong in your code?

Do you create an instance of my lib multiple times? Maybe that is one of the problems? If you would be able to send me an other example of code that has the leak issue would be great.


senthil_codeplex wrote Oct 17, 2012 at 8:38 PM


I think I made a mistake when I confirmed that the bug was fixed in the original sand box file. What was happening was it was throwing an exception which I did not see, I was only looking at the memory footprint and it was ofcourse stable (because it wasnt engaging the whole code).

I found a workaround for the exception and made the sandbox again, here is link directly to it, that you can open in your browser, and click on 'add something' while looking at the task manager (it averages about 2MB per click which leaks permanently)

If you want to look at the contents of this sandbox, I put it as a zip file over here:

Here are a couple points to keep in mind when you run the sandbox:

This test needs to be run from a server. Because if the html file is directly opened on the browser, we get a DOM exception (Uncaught Error: SECURITY_ERR: DOM Exception 18) when using the database. So the solution is to place this entire folder in the Public folder in Dropbox, copy the public link to testfile.html and access that link from the browser.

In the folder:

testfile.html and testscript.js: This creates a webpage with a single button. The JS script adds a single record into the db. And everytime the button is clicked, a where-equals query is done on the db. And each of this instance causes an increase in the memory of the Chrome tab.

diff_link2indexeddb.jpg and diff_link2indexeddb.worker.jpg shows the miniscule changes we did to the link2indexeddb files. In the former, we changed the path to the worker. And in the later, we included an extra check condition on a object to see if it's NULL before accessing one of its variables.

Hope this will make it easier to track down this bug.

thanks for helping out,

KDegrave wrote Oct 18, 2012 at 6:25 AM


I think I already know what the problem might be. I have been busy yesterday, and I have seen that all IDB... objects don't get cleaned up. I am doing my best now to clean up all the references made to them, but for now still no success in reducing them.

KDegrave wrote Oct 21, 2012 at 7:17 AM


I found the problem. It is in the logging it leaks. I didn't found a solution yet, but if you disable the the logging that you did it whould be fine. But take a new version. In the last version I have set the global enableLogging variable on true, and this enabled logging everytime. Even if you disabled in the constructor of the library.

senthil_codeplex wrote Oct 22, 2012 at 1:53 AM

Hi Kristoff,

Thanks for your efforts. I tested the latest version. The leak rate seems to have come down, but is not zero yet. I will know for sure after one day of usage with my app. It was averaging 1GB per day. I will report what is the new rate is later tomorrow when I have more data with the new version.

thanks again,

senthil_codeplex wrote Oct 22, 2012 at 8:55 PM

I have completed testing it for more than 24 hours now. We still have a large leak. It used to be around 1G per day, it is now at around 700MB. Also the leak can be detected in the sandbox file that I uploded last wednesday. (Keep clicking for about 10 times, and you will see a jump of about 2MB, it used to be a lot more, but it has come down after the logging was disabled)

KDegrave wrote Oct 23, 2012 at 6:25 AM

Well I used your example with the button and the insert to test the leak. Even after clicking multiple times I didn't see any difference in the heap when my logging was disabled.

senthil_codeplex wrote Oct 23, 2012 at 8:59 PM

Thats is very interesting., I will make sure I didn't screw up the setup and will test again this evening and let you know.

senthil_codeplex wrote Oct 25, 2012 at 10:17 PM

Hi Kristoff,

The leak has slowed down, but in this file for every click I add a 100 items so the leak becomes noticeable again.

Again here are the minor mods that were made to the files (FYI):

Here is a link to the whole zip file with the setup and a README file.

If you think we have the setup wrong, could you please put together a zip file with the correct setup like this and give me a link please.


KDegrave wrote Oct 26, 2012 at 4:45 PM

senthil_codeplex wrote Oct 27, 2012 at 9:50 PM

I am using chrome on mac osx.

Here is a screen cap of the task manager along with the page posted below. (

It ran up to about 200MB after 30 clicks or so.

Let me know if you could replicate it. Else we will have to get to the bottom of the replication issue first.

KDegrave wrote Oct 28, 2012 at 8:50 AM

Looks strange, on Chrome in windows I see the mem usage in the taskmanager of Chrome increasing. But when I take a look at the heap I don't see many differences. So I wouldn't have any idea what is causing the leak.

senthil_codeplex wrote Oct 28, 2012 at 10:37 PM

I will see if I can get you additional clues.

wrote Feb 14, 2013 at 8:20 PM

wrote Dec 7 at 8:08 AM