The comment indicates that calling LLSingletonBase::deleteAll() is optional
because the LLSingleton machinery implicitly calls that during final
static-object cleanup. That is no longer true.
The recent LLSingleton work added a hook that would run during the C++
runtime's final destruction of static objects. When the LAST LLSingleton in
any module was destroyed, its destructor would call
LLSingletonBase::deleteAll(). That mechanism was intended to permit an
application consuming LLSingletons to skip making an explicit deleteAll()
call, knowing that all instantiated LLSingleton instances would eventually be
cleaned up anyway.
However -- experience proves that kicking off deleteAll() processing during
the C++ runtime's final cleanup is too late. Too much has already been
destroyed. That call tends to cause more shutdown crashes than it resolves.
This commit deletes that whole mechanism. Going forward, if you want to clean
up LLSingleton instances, you must explicitly call
LLSingletonBase::deleteAll() during the application lifetime. If you don't,
LLSingleton instances will simply be leaked -- which might be okay,
considering the application is terminating anyway.
The logging subsystem depends on two different LLSingletons for some reason.
It turns out to be very difficult to completely avoid executing any logging
calls after the LLSingletonBase::deleteAll(), but we really don't want to
resurrect those LLSingletons so late in the run for a couple stragglers.
Introduce LLSingleton::wasDeleted() query method, and use it in logging
subsystem to simply bypass last-millisecond logging requests.
The LLSingletonBase::deleteAll() call late in LLAppViewer::cleanup() deletes
the LLSingleton(s) used by the logging machinery, among other things. Attempting
further logging after that call (such as our cheery "Goodbye!") has the
unfortunate effect of attempting to resurrect the deleted LLSingleton(s). Move
"Goodbye!" to just *before* the call.
Also, given that call, the manual references to a couple specific LLSingletons
in ~LLAppViewer() are (a) unnecessary and (b) cause attempted resurrection.
Eliminate both.
Need to work around a issue introduced with MAINT-7835. Due to the way the Firestorm
version of the login panel is initialized, setFields() will be called as part of
the panel ctor (via updateServer()), so that the values of the credential textboxes
will never be set when they actually should be
The dynamic_cast is *really* expensive here for >100k inventory items (up to 2s
freezes and there is a virtual function available to get the same information
much faster.
The shared pointer is passed by reference to LLVivoxVoiceClient::deleteSession() where
mSessionsByHandle.erase(iter) removes the last reference causing it to destruct while still
being accessed later on in the function.
The trouble lines are:
U8 * buffer = (U8 *) ALLOCATE_MEM(LLImageBase::getPrivatePool(), total_size);
if (cur_size > 0)
{
memcpy(buffer, mFormattedImage->getData(), cur_size);
}
If 'cur_size > mHttpReplyOffset + append_size' then 'total_size -= src_offset' will cause
total_size to be smaller than cur_size causing a write access violation on the memcpy.
Since the response is invalid it seemed best to make it follow the other failed partial condition.
This occurred after tp'ing away and after the region was already free'ed: in LLHUDManager::updateEffects()
the hud effect is actually not dead yet; update() gets called, detects that the source object is actually
marked dead so calls markDead() itself which releases the held pointer reference to LLVOAvatar which then
finally calls its destructor which calls getRegion() on a region which has already been free'ed creating
a read access violation.
Callstack (from a release build so optimizations obscure things a bit):
LLVOAvatar::logMetricsTimerRecord()
LLVOAvatar::logPendingPhases()
LLVOAvatar::~LLVOAvatar()
[External Code]
LLPointer<LLViewerObject>::unref()
LLHUDEffectLookAt::markDead()
LLHUDManager::updateEffects()
display()
LLAppViewer::frame()
WinMain()
Ansariel