Debug

Solving memory leak in javascript with try-finally

Changhong Fu — Sat, 29 Nov 2008 17:59:32 GMT

In my previous post, I discussed how return statement is executed in try-finally clause. So in following program:

string str = "original string";

try {

return str;

} finally {

str = "changed in finally";

}

the original value will be returned instead of the value changed in finally block. Would this feature be useful anywhere? Well, I can’t find anything in C#, but I can think up an example in javascript.

First, let’s have a look of following javascrip code:

function createDiv() {

var div = document.createElement("div");

div.onclick = function () { }

}

This looks quite ordinary javasript code, doesn’t it? But can you spot a potential memory leak in the code?

To prove there is a memory leak, let’s just open following html page in IE7:

<html>

<body>

function createDiv() {

var div = document.createElement("div");

div.onclick = function () { }

}

for (var i = 0; i < 100000; i++) {

createDiv();

}

</script>

</body>

</html>

This is what happened after I refreshed the page a few times. For each refresh, the memory usage was increased by approximately 100M, and it would never go down. Even I went to another page or closed the tab page, the memory was still held by IE7. Shut down IE is the only way to reclaim the memory back! (Note: this memory leak won’t happen in firefox 3)

The cause of the memory leak is circular reference. As you may know, calling a javascript function will create an object. This object is not accessible from your code, but it is used for javascript to maintain its scope chain. So, in the code above, when createDiv is called, a scope object is created which has a property “div” which points to a div object created by document.createEmelemt(“div”). Then “div” object’s onclick property is assigned with a function object defined inside function “createDiv”. As the function for onclick lives inside the closure, it has a reference of its parent scope object. So, have a look of the following picture, there is clearly a circular reference. That's why it causes memory leak.

So, how can we fix the problem? Of course, the easiest way is to assign div = null or move onclick function outside the createDiv like this:

function createDiv() {

var div = document.createElement("div");

div.onclick = function () { }

div = null;

}

function createDiv() {

var div = document.createElement("div");

div.onclick = handleClick;

}

function handleClick() {};

But what if onclick need to access a variable defined in createDiv and you want to return div from createDiv? Now, try-finally will help.

function createDiv() {

var div = document.createElement("div");

var greeting = "hello world!";

div.onclick = function() { alert(greeting); };

try {

return div;

} finally {

div = null;

}

Now, in the try block, div is returned properly, and the link between createDiv scope object and div object is guaranteed to be broken by assigning createDiv’div variable (note, it is just the div variable, not the div object itself) to null in the finally block.

Debug into .Net Framework Source Code

Changhong Fu — Thu, 11 Sep 2008 11:53:15 GMT

I was writing some WPF testing code today. It was extremely simple code which just programmatically creates a Rectangle and adds it to a canvas. The code this something like this:

Rectangle rectangle = new Rectangle

{

Fill = new SolidColorBrush(Colors.Blue),

Stroke = new SolidColorBrush(Colors.Blue),

Width = 150,

Height = 120

};

rectangle.SetValue(Canvas.LeftProperty, 100);

rectangle.SetValue(Canvas.TopProperty, 100);

canvas.Children.Add(rectangle);

However, I got an exception on rectangle.SetValue(Canvas.LeftProperty, 100), saying "'100' is not a valid value for property 'Left'."

It didn’t take me long to release that Canvas.LeftProperty actually requires a double instead of an integer, but I was surprised that it couldn’t handle an integer. Normally, in a .NET program, we wouldn’t have to worry about the implicit cast from integer to double, right? So, I was just curious and want to find more about how DependencyObject.SetValue is implemented and wanted to have a look of the .NET framework code.

Normally, when I want to do this, I will just use .NET Reflector, but I just heard from my friends that I can debug into .NET framework code. So, why not give it a go?

So, followed ShawnBurke's great post Configuring Visual Studio to Debug .NET Framework Source Code, I got my Visual Studio set up and ready to go.

Now, fire up my program, set a break point, and in the CallStack panel, there are list of items are greyed out which are the .NET Framework code as Visual Studio doesn’t have the debug symbols. So, just right click, and "Load Symbols", Visual Studio will load them from the debug symbol server you have specified (ShawnBurke’s post above explains how to do it).

When the debug symbols loaded (it may take a few minutes. PresentationFramework.pdb has 12Mb and PresentationCore.pdb has 16Mb), you will know as greyed out items on CallStack turn black.

Hit F11, now, you can see this:

Cool, isn’t it? We are now in .NET framework source code! Writing a .NET program could be as cool as writing in java! (just kidding)

After I played around a bit and dug through some .NET framework code, I found it pretty much just check the value passed in is an instance of the type DependencyProperty defined of. The code is something like this:

if (!propertyType.IsInstanceOfType(value))

{

return false;

}

If it returns false, an exception will be thrown from SetValueCommon.I guess WPF could have done better to handle an integer as a double, after all, if we want to set a location programmatically, normally we would just use an integer, right? Anyway, it is not really my point for this post. I really just want to show how to debug into .NET framework code here.

Pretty cool, isn’t it? So, what is not so cool?

Well, did find a couple of things not as cool as I expected.

You have to load debug symbols every time you run the program. It will load from your local cache once it is downloaded from the server, so it won’t take long. But you do have to right click the CallStack, and "Load Symbols" every time.

In .Net Framework code, variable values will not be shown properly. You will have "Cannot evaluate expression because the code of the current method is optimized."