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.
(transplanted from 737e28ec6b4d74f3ff915a4effc13d7b615a6a9b)
The fix in fllowing:
LLTextureFetch has object LLTextureInfo which is has Recorder object.
The recorder object activate (Recorder::handleStart()) self AccumulatorBufferGroup
(Recorder::mBuffers into the current (LLTrace::get_thread_recorder()) ThreadRecorder object
which created (as I understand) one per thread, and time to time send accumulated data to the master ThreadRecorder.
The problem is that LLTextureFetch also can uses from the main thread.
I decide add parameter to CTOR LLTextureInfo(bool postponeStartRecoreder) -
if it false the recorder start immediatly in LLTextureInfo CTOR body, if true we need to start it manually.
Also I add another one LLTextureInfo in LLTextureFetch::mTextureInfoMainThread which is intended
for accumulate data from the main thread.
The postponed Recorder started/stoped from LLTextureFetch::startThread()/endThread().
The problem was that class-static LLUrlEntryParcel::sRegionHost was being
initialized by copying class-static LLHost::invalid. Naturally, these two
statics are initialized in different source files. Since C++ makes no promises
about the relative order in which objects in different object files are
initialized, it seems we hit a case in which we were trying to initialize
sRegionHost by copying a completely uninitialized LLHost::invalid.
In general we might attempt to address such cross-translation-unit issues by
introducing an LLSingleton. But in this particular case, the punch line is
that LLHost::invalid is explicitly constructed identically to a
default-constructed LLHost! In other words, LLHost::invalid provides nothing
we couldn't get from LLHost(). All it gives us is an opportunity for glitches
such as the above.
Remove LLHost::invalid and all references, replacing with LLHost().
Dave Parks