Memory Leak in My .Net Application

.Net does not make memory leaks a thing of the past….but it does very nicely take away most of the burden from developers.

Our WinForms app is due to go live very soon and we’ve noticed that we have a memory leak. These are the two errors we were receiving…

OUT OF MEMORY EXCEPTIONS

We were receiving two differnt types of exceptions:-

  1. Error Creating Window Handle.
  2. A Generic Error Occured in GDI+

The errors intermittently in random parts of the application but it did seem to occur more frequently in one ‘problem’ area.

IDENTIFYING A MEMORY LEAK

Open Task Manager, goto Views -> Select Columns and check USER Objects and GDI Objects. Why do we care about these? As it turns out, if either of these numbers hits 10000 you will get an out of memory exception. User objects produces the Handle error and GDI produces the GDI error (oddly enough).

UserGDIcolumnselect

Now run your app and watch those numbers.  Ideally focus on one specific area where you can repeat an activity such as opening and closing a modal window (the memory leaks we had were occuring around creating and disposing controls.) If the numbers go up and never come down then it’s likely you have a leak (allow some time for the Garbage Collector – GC – to run).

PLEASE DISPOSE OF YOUR OBJECTS THOUGHTFULLY

So the app had a memory leak, what then? First I checked that IDispose was correctly and that we were calling Dispose where necessary.

I’m not going to discuss how to do this in this post but here’s a couple of links to get you started…

http://msdn.microsoft.com/en-us/library/b1yfkh5e.aspx
http://www.codeproject.com/KB/cs/idispose.aspx

Once this was done the User Objects count was under control. GREAT….but the GDI count was improved but there was no doubt that it was still growing unchecked. So what then? This article led me to ANTS Profiler and few interesting discoveries that I’ll discuss in my next post…

Other Resource/Useful Links

This is a very interesting article about ‘Windows are not cheap objects’
http://blogs.msdn.com/oldnewthing/archive/2005/03/15/395866.aspx

Advertisements

VSS File Date on Get Latest

VSS has many settings, most of which most of us leave set at the default.

One of the few settings I think should be changed is the local file date. Why?

The default setting is Current. This means that when you do a get latest the Date Modified shown in windows explorer for the file will be the current time. Knowing the time that you last got the latest version isn’t very useful information, it is much more useful to know when the file was actually last changed.

So to ensure you get that info just change the setting shown below to Modification and from now on when you do a get latest it will always be the date the file was last modified.

Much more useful 🙂

Making the Change

Open VSS and go to ->Tools-> Options

Change ‘Set Date/time on local files’ from Current to Modification:-

Done!

Secrets for Setting up Continuous Integration

I’ve set up CI in my last two roles and have spent a little bit of time trying to simplify the process whilst doing it and thought I’d share a few ‘secrets of sucess’ for getting CI up and running.

So what makes CI easier?

1. GENERATE YOUR BUILD FILES

I wrote my own code generator that searches through my entire dev directory for project files (I work with .Net so it simply looks for .csproj files) and generates a NAnt build file for each project file. I also generate the master.build file. If there isn’t already an existing CodeSmith template for this type of thing then it’s not too hard to create your own generator (code generator = fancy string builder). This is what I’ve done.

Generating your build files is also important because you then know that all of your projects are built in a consistent manner. Plus when you make the build files cleverer you can easily apply those changes across all of your build files at the push of a button (ok a few buttons maybe).

2. AUTOMATE AND CONTROL YOUR DATABASE UPDATE PROCESS

This is a whole other topic in itself but I’ll try to keep it brief (of course ignore this one if your app does not hit a database). The biggest challenge you will face is handling database updates effectively. Your build box, test box and of course production box all have their own database and ideally each developer runs their own local copy (unless size does not permit). The problem is, when a developer checks in his unit of work which includes a database change (new table and some data for example), when the build kicks off how do you ensure that those database changes are run against the build boxes database?

You must have an automated program that runs any new scripts and this program must be one of the first things run as part of your build process. So what if one of the scripts fails? Ideally your program will run all scripts in a transaction and simply rollback the transaction if any of the scripts fail. This will work on SQL Server but sadly on Oracle any DML script will cause a commit of the transaction so you must find another (like backup first and restore on failure).

Developers use the same program to update their local database and the program is also used when promoting to other environments. By the time you run it against production you will potentially have hundreds of scripts (which I have experiences) so make sure you have a good naming convention (or other technique) that ensures the scripts get run in the correct order.

All changes to the database must be made with a script, no exceptions. (not exactly a new rule but it amazes me how many people do not follow it!)

I wrote my own program to handle this and I’d be very interested to hear what others have done.

3. GET ‘BUY IN’ BEFORE STARTING

From developers to the CIO. The CIO needs to understand the benefits that this new process will provide because it is going to take time (and money) to get it setup (money and time that will DEFINATELY be recouped over time).

CI forces a more disciplined approach to software development, some developers will not like that so it’s important that they understand the benefits that they will see with the new process (like knowing that doing a get latest will always return a working copy of the source!). Developers will get annoyed with the new process if they don’t understand it properly and keep breaking the build.

4. GET A DECENT BUILD BOX

We are still working with a crappy old desktop. It takes longer to build and we continually have clean it up as it fills up pretty quickly. Frustrating!

5. MAKE RULES FROM DAY 1

#1 – If you break the build it becomes your highest priority to fix it.
#2 – If the build is broken no further checkins are allowed until it is fixed. (except of course by the guy fixing)
#3 – No chicken runs…means no checking in just before you go home. (this rule is the only one that is flexible)

6. CLEAN BUILD

If you delete everything in your development directory on you build box (i.e. where all of the source code is) and then start the build it….it should work! If it doesn’t then there is a dependency in there somewhere that is not in source control.

Every developer I have spoken to who has used CI tells me there is no way they could work in an environment that does not use it, so it may present some challenges setting it up but it is well worth it!

Update…Check out this article too!