Apolon's Software Torq

Over the last three or so months, I’ve been eyeing an Athlon XP 3800+ X2 processor upgrade but just couldn’t justify the expense given the delta in performance between a single processor XP3500+ and the cheapest dual processor version available at the time. A price check was done every couple of weeks, but the suppliers didn’t budge an inch. After hearing murmurings of the Intel Core Duo 2 benchmarks, I thought they’ve got to drop prices when that thing gets released. Yep, they sure did.. around 60% for what I was looking at. The end result was the in stock purchase of an XP 4200+ X2. Sweeeet. It feels good to know that there’s another bout of price/performance improvements coming down the pipeline.

There was one sticking point in the upgrade process. The old processor’s heat sink would not budge. You know that point where you force something and it gets to the point of questioning “should I be doing this?”. Fortunately I held back and only applied “suitable force” before checking on the web for other people’s experiences. The end result was that a hair dryer was blown across the existing heat sink which made the old heat sink paste loosen up. From then on it was clean sailing finishing up with a satisfying red and green graph showing in the Sysinternal’s process explorer program for each of the processor cores.

Global search engines are a wonderful thing. I’ve had an intern working on software development here over the vacation break and at odd times during the week. He had a question the other day about “what we did to solve problems before google”. Well, solve problems we did but a lot more slowly and with much more trial and error. The pace of technology change is just incredible and the ubiquity of broadband internet access will just accelerate it.

Posted by Apolon at 5:08 PM | Permalink | Comments | links to this post

The exercise discussed in the .Net Memory Leaks post lead to the identification of a class of memory leak issues in the application being profiled. The class of memory leaks are as a result of an object being held in memory solely by its listing within an event handler. The object has no purpose existing other than being registered with an event handler when it did have a purpose in life. My conclusion is that it would be more beneficial to application development if event handlers only had weak references to the target objects that are called when the event fires (at least by default). One of the major benefits of .NET events is that the class exposing the event is loosely coupled from the class subscribing to the event. All that is common between the provider class and the subscriber class is the event handler delegate type and the event arguments class. This suggests that in most scenarios, the lifetimes of the provider instance and the subscriber instance should not be strongly linked.

Given my experience with the WeakReference class, it would have been useful if there some easy way of making a event only reference its subscribers using weak references. Based on this requirement, I did some research into what has already been done in that area. Some useful links are included below. They are date ordered to provide some context for the author’s words. Unfortunately its not a satisfying read as there doesn’t seem to be a standard way of dealing with this issue “automatically”.

Some authors take the view that the correct way of doing this is making sure that event unsubscription occurs in the FormClosing event of a Windows form or the Dispose method of an IDisposable. Sure this makes sense, but it takes away from the promise of developer productivity that is one of strengths of .NET. We leverage the garbage collector to deal with many of our memory management issues, why not include event subscriber dependencies? Some cursory analysis of the problem tends to suggest that the only real solution that is convenient to use and does not compromise performance would have to be done in a combination of the CLR, compiler and the core framework i.e. in Microsoft’s domain. For example the .NET 2.0 generics functionality won’t let you use EventHandler as a generic constraint. Even if it did, I’m not sure if EventHandler.Invoke( object sender, EventArgs args ) can be called on a delegate derived from EventHandler. Anyway here’s the list of links:

Jul 2003: http://weblogs.asp.net/fbouma/archive/2003/07/11/9980.aspx

Sep 2003: http://discuss.develop.com/archives/wa.exe?A2=ind0309c&L=dotnet-clr&D=0&T=0&P=17132

May 2004: http://blogs.msdn.com/greg_schechter/archive/2004/05/27/143605.aspx

June 2004: http://www.seedindustries.com/blog/x/2004_06_01_archive.html#108656795427367272

Jun 2004: http://www.interact-sw.co.uk/iangblog/2004/06/06/weakeventhandler

Jul 2004: http://weblogs.asp.net/fmarguerie/archive/2004/07/27/198489.aspx

Jan 2005: http://damieng.blogspot.com/2005/01/lapsed-listeners-memory-leaks-with.html

Feb 2005: http://www.bluebytesoftware.com/blog/CommentView,guid,0d89ec27-a914-4e06-8eac-8cb8d5879566.aspx

Mar 2005: http://wesnerm.blogs.com/net_undocumented/2005/03/clr_dinner.html

Oct 2005: http://www.codeproject.com/csharp/weakeventhandlerfactory.asp

Posted by Apolon at 1:24 PM | Permalink | Comments | links to this post

Conceptually I knew that eventually there would be a need to diagnose a memory leak problem in a .NET application. Sure a garbage collected environment automatically sorts out whole sets of memory problems, but it doesn’t stop memory leaks where you put an object in some container and “forget” about it. You legitimately need the container to hang around, but the object should have been chucked in the garbage. Its actually quite easy to do, so its surprising that four years of C# development work has passed without the need to resolve a memory leak issue until today.

There have more than likely been other memory leaks but they haven’t become an issue. The vast memory available in modern machines and the typical life cycle of some classes of programs help to hide the occurrence of memory leaks. For example an end user closing their application at “quittin time” means that most Windows form app scenarios get a clean start every day. This a cheat’s way of resolving memory leaks!

Experience with C++ has shown, you don’t stuff around with trying to sort out memory leaks using manual coding techniques. The best approach is to leverage a tool otherwise you waste a ton of time. The first tool I tried was the beta release of dotTracer 2.0 from http://jetbrains.com. Being somewhat of a collector in nature, dotTracer was tried first because of a recent purchase of Resharper which has been going well. Unfortunately the beta functionality wasn’t quite there yet to practically resolve the memory leak issue.

Since I already have Purify for all C++ memory analyis, it was worth giving it a go on a .NET problem. Running a .NET program through Purify memory analysis resulted in sluggish performance for the application during profiling. It was bearable but .NET specific memory profilers seem to run the profiled apps much faster. Quick app runs make it easier to go through a debug cycle and chase down problems. Also the user interface for analyzing object instance differences was hard to work with.

The next memory profiler that was used was from http://memprofiler.com. I had actually experimented with it out of interest a while back. My memory of it was of an intimidating user interface i.e. hundreds of thousands of object references staring at you from behind a grid. Now that there was a real problem to sort out, some effort was put into understanding the user interface. It turned out to be very effective in identifying which objects shouldn’t be around and traversing the object relationships to figure out what is keeping them around. The first impression is that fancy graphics showing object relationships via graphical links/trees should be an easier to use metaphor for identifying memory leaks. In practice it turns out that being able to quickly traverse the relationships between the objects in memory is more useful in identifying the cause of objects hanging around when they shouldn’t.

Memory leak identification in .NET is based around running a program to a certain point and then taking a snapshot. This acts as a base line for the objects you expect to be in memory. You then perform a program task and complete the task so that you would expect the managed object status to be the same as that in the base line snapshot. An example is closing a form once you’ve done with the form. The memory profiler’s comparison tool can then be used to look at the difference in object instances between the base line and another snapshot. The live objects in this difference set are the potential memory leaks.

Cutting a long story short, my memory problem was identified by using the http://memprofiler.com tool. It was due to an interaction between a long lived business object list and a shorter lived form. The form subscribed to a ListChanged event in the business object but didn’t unsubscribe when the form was closed. So even though the form was closed, the long lived business object kept the form object from being garbage collected. Form references were being accumulated in the ListChanged delegate’s linked list causing the memory leak. Being a cheapskate I’ll hold off buying the profiler tool until its next needed, but at least then its a straight forward buy based on experience.

Posted by Apolon at 5:41 PM | Permalink | Comments | links to this post

 By default in Windows Forms a single line text box will sound an annoying ding/bell when the user presses the Enter key. Presumably this is suppose to inform the user that they shouldn’t need to press the Enter key as it is a single line text box, but its an annoying side effect if you want to perform some action when the enter key is pressed. An example in an application we are working on is a find textbox at the bottom of a tree control. Its convenient just to press enter once the text has been typed rather than moving the mouse over to another button and clicking. Note that these controls are on the main form so associating the enter key with closing a dialog is not suitable.

A web search came up with the following solution (found in many locations). You consume the enter key so that the beep is not sounded. It seems like somewhat of a hack, so if anyone has a better approach please leave a comment.

private void findTextBox_KeyPress( object sender, KeyPressEventArgs e )

{

    if ( e.KeyChar == '\r' )

        e.Handled = true;

}

Posted by Apolon at 10:18 AM | Permalink | Comments | links to this post

If you are using V7+ of the Xwin32 package, then there is the potential to get weird characters on your MacroView X window displays. See the box characters in the xfontsel screen capture below. This occurs because both the iso8859 and iso10646 registry values are available to match common MacroView font specifications. The selection of the iso10646 registry is not compatible with the MacroView font implementation and results in unreadable text.

The solution is to change the order of fonts in the Xwin32 font path so that both the 75dpi and 100dpi fonts are earlier in the path than their unicode equivalents.

Posted by Apolon at 2:01 PM | Permalink | Comments | links to this post

ADSL2+ is finally available at my local exchange. I’ve been watching the other exchanges in the Perth area get switched over to ADSL2+ from ADSL over the last year. It was incredibly frustrating…waiting…waiting. The end result is 20 mbps downstream and 1mpbs upstream – which is fantastic compared to 1.5 mbps. The responsiveness change isn’t that noticeable except when lots of separate apps are downloading/communicating concurrently but nothing is slowing down. Even better is when you work with a server site that can really pump the data through.

Posted by Apolon at 5:12 PM | Permalink | Comments | links to this post

Ayende Rahien has a post on multi tasking and real estate and asks the question: How does your taskbar look at the moment?

I used to have it two levels deep on the bottom of the screen – three deep seemed to eat into the main display too much. Now that my main machine has a wide screen monitor, the preferred approach is docked to the left of the screen. This allows all the running programs to be easily listed and a good portion of their titles are visible. It also provides a decent amount of room for the quick launch buttons, a search box and the system tray (or whatever its official name is). It would be handy if the various video players could dock themselves neatly into the taskbar so I can watch “talking head” videos in a small region of the screen without obscuring the main work area.

Posted by Apolon at 3:22 PM | Permalink | Comments | links to this post

What do you do when you see a Java windows application complain that there something wrong with its pdf reader? Well you look at its console output of course. Console output? … Yes console output. 

java.io.IOException: CreateProcess: "C:/Program Files/Adobe/Acrobat 6.0/Reader

/AcroRd32.exe" /p /h "C:\Program Files\ECIClientV5\temp\eci-temp-1.pdf" error=3

java.io.IOException: CreateProcess: "C:/Program Files/Adobe/Acrobat 6.0/Reader/A

croRd32.exe" /p /h "C:\Program Files\ECIClientV5\temp\eci-temp-1.pdf" error=3

        at java.lang.Win32Process.create(Native Method)

        at java.lang.Win32Process.<init>(Unknown Source)

        at java.lang.Runtime.execInternal(Native Method)

        at java.lang.Runtime.exec(Unknown Source)

        at java.lang.Runtime.exec(Unknown Source)

        at java.lang.Runtime.exec(Unknown Source)

        at java.lang.Runtime.exec(Unknown Source)

Acrobat 6.0 is no longer installed so http://www.sysinternals.com/Utilities/Junction.html came to the rescue. It provides something similar to linked files in Unix. There are a heap of great utilities over at sysinternals.com. Brilliant stuff.

$ junction "c:\Program Files\Adobe\Acrobat 6.0\Reader" "c:\Program Files\Adobe\Acrobat 7.0\Reader"
Junction v1.04 - Windows junction creator and reparse point viewer
Copyright (C) 2000-2005 Mark Russinovich
Systems Internals - http://www.sysinternals.com
Created: c:\Program Files\Adobe\Acrobat 6.0\Reader
Targetted at: c:\Program Files\Adobe\Acrobat 7.0\Reader

Posted by Apolon at 2:23 PM | Permalink | Comments | links to this post