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().
Merging from server-1.26 to trunk
Only a few conflicts:
scripts/farm_distribute : the upload rate in trunk was even more
conservative than the one I switched to in
1.26, so kept the trunk version.
indra/llcommon/llversionserver.h : did svn revert to keep trunk
indra/newsim/lltask.cpp : svn is weird. The merge conflict was one
that it's not obvious why it was there.
However, Simon and I looked at it, and the
solution was obvious : keep the trunk blob
where the conflict was flagged.
indra/lib/python : conflict was differing versions of the eventlib
extern. did svn revert . to keep trunk.
Oz Linden