That is, when the underlying LLError::Settings object is destroyed -- possibly
at termination, possibly on LLError::restoreSettings() -- the passed Recorder*
is deleted.
There was much existing code that seemed as unaware of this alarming fact as I
was myself. Passing to addRecorder() a pointer to a stack object, or to a
member of some other object, is just Bad. It might be preferable to make
addRecorder() accept std::auto_ptr<Recorder> to make the ownership transfer
more explicit -- or even boost::shared_ptr<Recorder> instead, which would
allow the caller to either forget or retain the passed Recorder.
This preliminary pass retains the Recorder* dumb pointer API, but documents
the ownership issue, and eliminates known instances of passing pointers to
anything but a standalone heap Recorder subclass object.
On Windows, Bad Things happen when apr_proc_create() is allowed to pass TRUE
to CreateProcess(bInheritHandles). For instance, the open handle for a new
installer executable file being downloaded by the background updater gets
inadvertently passed to a couple slplugin.exe instances. When the viewer
finishes downloading, closes the file and tries to remove it, Windows balks
because the file is still open by another process. Require an apr_suite
package that includes the new Linden apr_procattr_inherit_set() extension, and
call it to turn off CreateProcess(bInheritHandles).
Attempting to debug an observed LLFile::remove() failure, I was floored to
find that remove() made no attempt whatsoever to report its lack of success!
Add warnif() function to log errno text in platform-dependent way. Support the
notion that for some functions, certain errno values are acceptable -- e.g. we
expect stat() to frequently hit ENOENT -- and need not be logged.
Add commented-out Windows-specific logic to try to provide further information
in the case of EACCES ("Permission denied," e.g. another process has the file
open). To use, enable the code block, download handle.exe and turn on DEBUG
logging for LLFile. handle.exe can be obtained from:
http://technet.microsoft.com/en-us/sysinternals/bb896655
Incoming changes from two different project repos left viewer-development with
LLInventoryModel::removeItem() and removeCategory() plus free functions
remove_item() and remove_category() in llinventoryfunctions.cpp.
remove_category() was actually the better implementation; migrated its body
into LLInventoryModel::removeCategory(). Clearly the previous state of affairs
-- with LLInventoryModel::removeItem() plus a remove_category() free function
in a very different source file -- fooled two different developers into
overlooking the other of the pair. Unfortunately we each added different
"missing" functions, leaving us with a complete set of four.
Fix existing references to remove_item() and remove_category() free functions.
In a number of places, the viewer uses a lookup based on std::type_info*. We
used to use std::map<std::type_info*, whatever>. But on Linux,
&typeid(SomeType) can produce different pointer values, depending on the
dynamic load module in which the code is executed. Introduce
LLTypeInfoLookup<T>, with an API that deliberately mimics
std::map<std::type_info*, T>. LLTypeInfoLookup::find() first tries an
efficient search for the specified std::type_info*. But if that fails, it
scans the underlying container for a match on the std::type_info::name()
string. If found, it caches the new std::type_info* to optimize subsequent
lookups with the same pointer.
Use LLTypeInfoLookup instead of std::map<std::type_info*, ...> in
llinitparam.h and llregistry.h.
Introduce LLSortedVector<KEY, VALUE>, a std::vector<std::pair<KEY, VALUE>>
maintained in sorted order with binary-search lookup. It presents a subset of
the std::map<KEY, VALUE> API.
Making llmanifest.py support library-file wildcards allows viewer_manifest.py
to avoid specifying the exact version number of every shared library we want
to package. Specifying "libfontconfig.so.*" was copying the libfontconfig.so.1
symlink as well as the libfontconfig.so.1.4.4 binary. To my dismay, packaging
that symlink makes the Linux viewer fonts look WORSE! I suspect that means
that the released Linux viewer completely ignores our packaged
libfontconfig.so.1.4.4 library, finding the system fontconfig instead. But
that would be a whole different project. For present purposes it suffices to
make the updated viewer_manifest.py copy the same files as the older one.
Brad Payne (Vir Linden)