| Age | Commit message (Collapse) | Author |
|---|
|
|
|
as in release
|
|
|
|
|
|
the forcing to reversible for small textures.
|
|
Now LLProcess explicitly requests APR to limit the handles passed to any child
process, instead of wantonly passing whatever happens to be lying around the
parent process at the time.
This requires the latest APR build.
Also revert LLUpdateDownloader::Implementation::mDownloadStream to llofstream
(as in rev 1878a57aebd7) instead of apr_file_t*. Using APR for that file was a
Band-Aid -- a single whacked mole -- for the problem more systemically
addressed by apr_procattr_constrain_handle_set().
|
|
|
|
|
|
|
|
|
|
|
|
It appears that the LLTrans machinery, or at least the way it's used in this
program, is buggy: linux-updater.bin has been crashing. Tracebacks and
experimentation identify LLTrans as the culprit, so replace it with baked-in
string constants copied from strings.xml. (linux-updater.bin was already
producing English-only messages because the update_install shell script that
calls it was specifically passing the English version of strings.xml.)
|
|
|
|
|
|
|
|
|
|
on and off.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HTTP when all objects loading are done.
|
|
|
|
|
|
|
|
|
|
As a viewer architect, I would like to understand how fast each of the components of the texture pipeline can run in isolation
|
|
disconnect.
Added checks for LLViewerRegion pointer in LLViewerObject being invalid.
|
|
Mindful that some autobuild packages populate only packages/lib/release
(rather than packages/lib/debug), Linking.cmake always appends
packages/lib/release to CMake's link_directories() directive. But since CMake
always appends CMAKE_BUILD_TYPE to those directories, we end up with a phantom
packages/lib/release/Release directory on the search path. This would be
harmless except that the Mac's 'ld' command produces a warning. These warnings
quickly make TC's "Important Messages" output useless. Try appending
packages/lib/release only when the build type isn't already Release.
|
|
the logs when passing
WOLF-363: (partial) correct ordering of cleaning build dir vs running
'autobuild install'
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This handles the case when the target file doesn't exist, just as APR_TRUNCATE
handles the case when it does.
Strengthen error checks concerning downloaded installer file from
ll_apr_warn_status() to ll_apr_assert_status(). Failing to recognize (e.g.)
failure to open that file only leads to mysterious crashes down the road; this
removes the mystery.
|
|
|
|
Reviewed by Ted.
|
|
On Windows, calling CreateProcess(bInheritHandles=FALSE) is the wrong idea. In
that case, CreateProcess() passes NO handles -- even the files you've
explicitly designated as the child's stdin, stdout, stderr in the STARTUPINFO
struct! Remove LLProcess code to tweak bInheritHandles; we should also remove
the corresponding (useless) APR extension.
Instead, given that the Windows file-locking problem we've observed is
specific to the viewer installer .exe file downloaded by the background
updater logic, use APR file I/O for that specific file. Empirically, both
llofstream and std::ofstream seem to make the open file handle inheritable;
but apr_file_open() documentation says: "By default, the returned file
descriptor will not be inherited by child processes created by
apr_proc_create()." And indeed, it does appear to sidestep the locking problem.
|
|
|
|
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.
|
|
|
|
|
