Potential Crash: Display Group RootSelection item callbacks; Seen in Purify.
Gnats 5002 -- Phil Weinstein, CADSWES, 12-31-2010.

There is a callback registration maintenance problem with (not large) 
Account and Supply (Display) Groups -- and maybe also Object and Link 
Groups. This has been detected with Purify on Windows, during program exit 
(clearing the workspace).  It could result in a crash, but doesn't seem to, 
for non-fundamental reasons -- i.e. it readily could.  This problem exists 
in RiverWare 6.0.1 (as well as in 6.1 Development).

The problem is in the "CallbackReceiver" mechanism which "efficiently"
maintains callbacks for a Display Group's "Root*" pointers in the Group's
RootSelection.  In the case of the problem with an Account Group, the 
callback isn't being erased when the Account is deleted.  So when the 
Account Group is ultimately cleared, it dereferences an Account pointer 
for an Account that no longer exists. 

See the Purify and debug trace output files in the bug5002 directory:

  purify-2010dec31a.txt
  trace-2010dec31a.txt

This problem will occur ONLY if used with sufficiently SMALL Account and
Supply Groups -- UNDER 50 ITEMS.  If there are over 50 items, callbacks 
for ALL items (of the particular type) are registered -- and that doesn't
exhibit this problem.  (The memory violation is in the under-"threshold" 
stanza of the CallbackReceiver::_helpAccountCallbacks method, which 
maintains individual callbacks on each member instance).

POSSIBLY, the "expected" callback type is not always generated in ALL
deletion scenarios -- FOR EXAMPLE -- ACCOUNT_DELETED instead of 
SIMOBJ_ACCOUNT_DELETED.  (This is just a guess).

Note: Depending on how this is dealt with, we need to be careful about 
adding or removing RootSelection items and accompanying callbacks in 
such a way that the Under/Over "threshold" (50) status changes for the
Display Group.  That could result in the wrong type of callback deletions 
to occur in the "_help" method cited above.  This is a bit fragile.
(A flag field to indicate how callbacks were registered would be prudent 
-- and this probably is relevant for ALL FOUR types of Display Groups).

A smaller bug model will be devised.  But an initial one has been provided.
(1) Load a model from the bug5002 directory.
(2) Switch to Accounting View
(3) Delete an Account which is in an Account (Display) Group, and optionally
 which is involved in a Supply.
(4) Exit RiverWare.

... Generally (or maybe virtually always), NO PROBLEM will be apparent, 
except when running in Purify, or when generating diagnostic trace output
devised specifically to examine this problem.

---