Bug 225911 - Exception received after deleting a profile containing a connection
Summary: Exception received after deleting a profile containing a connection
Status: RESOLVED FIXED
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: 3.0   Edit
Hardware: Macintosh Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: 3.0 M7   Edit
Assignee: David Dykstal CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 228774
  Show dependency tree
 
Reported: 2008-04-06 15:18 EDT by David Dykstal CLA
Modified: 2008-04-24 17:30 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Dykstal CLA 2008-04-06 15:18:29 EDT
Steps to reproduce:
Create a new profile P and a connection C within that profile.
Delete the profile P using the Team view. 
Create the profile P again.
Attempt to create connection C in profile P again.
Get either a "Widget Disposed" exceptino or an "IllegalArgumentException"

This appears to be caused by a disposed widget being left in the element map of the StructuredViewer on which the SystemView is based. I suspect the widget representing the connection is being disposed, but that it is not being properly removed from the map due to ElementComparer problem. The problem is fairly rare but consistently reproducible.
Comment 1 David Dykstal CLA 2008-04-24 16:41:50 EDT
The bug was in the way the absolute name was formed for deleted hosts. This is used in the hash calculation for the ElementComparer. The absolute name for a host includes its profile name. If a profile deletion caused the host deletion then the absolute name, and thus its hashcode determined by the comparer, changed. This was causing the map of objects->widgets to get mixed up and a disposed widget to be left in the map.

The fix was to ensure that absolute host names, even for hosts with deleted profiles, included the profile name.
Comment 2 Martin Oberhuber CLA 2008-04-24 17:03:59 EDT
Thanks Dave. In fact the important point is that an absolute name must always uniquely identify an object and must never change -- that's what the Javadoc in IRemoteObjectIdentifier says.