LLAppViewer's heap LLWatchdogTimeout might be destroyed very late -- as late
as in LLAppViewer's destructor. By that time, LLAppViewer::cleanup() has
already called LLSingletonBase::deleteAll(), destroying the LLWatchdog
LLSingleton instance.
But LLWatchdogTimeout isa LLWatchdogEntry, and ~LLWatchdogEntry() calls
stop(), and stop() tries to remove that instance from LLWatchdog, thus
inadvertently resurrecting the deleted LLWatchdog. Which is pointless because
the resurrected LLWatchdog has never heard of the LLWatchdogTimeout instance
trying to remove itself.
Defend LLWatchdogEntry::stop() against the case in which LLWatchdog has
already been deleted.
This change is not guaranteed to fix this issue as the issue
is difficult to repro, but there was a sketchy case
group member responses come back from the simulator in message
packets. For very large numbers of members, there may be a
large number of packets received. The member data is placed
in a structure of type LLGroupMgrGroupData, based on the group
id.
The problem is, if the user refreshes the group before the entire
contents of the previous request comes back, response packets from
the previous request will be intermingled with the responses from
the refresh.
Both the request call and the response handler would create the
group data structure, if the structure wasn't already there. There
may be a case where a response from the previous request causes
creation of the group data, populating it with the contents of the
response, and the responses from the second request would use that
group data structure.
Also, cleaned up some comments and variable names to be consistent
Ansariel