| Age | Commit message (Collapse) | Author |
|---|
|
There are duplicate LLTrace::BlockTimerStatHandle key strings declared in
llsettingsdaycycle.cpp and llsettingswater.cpp -- the only instances of
duplicate BlockTimerStatHandle keys in the viewer code base. SL-13467 tracks
intentional crashes due to duplicate LLInstanceTracker subclass instances with
one of those keys. The simplest experiment to try to eliminate those crashes
is to ensure that every BlockTimerStatHandle in the code base is unique.
|
|
|
|
|
|
following promotion of DRTVWR-508
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The observed failure is that SLVoice, on relaunch, produces an error that
bind() returned EADDRINUSE and terminates. Using a different port every time
we relaunch avoids that collision.
|
|
Enable the body of the existing ll_debug_socket() function (on Mac as well as
Linux), but using tag "Socket" so you can turn on its log messages without
emitting *all* debug messages.
|
|
It can happen that we arrive at logoutOfVivox() with some other message
queued on the LLEventMailDrop in question. If logoutOfVivox() assumes that
other message is logout and exits, then subsequent code gets confused.
Introduce a loop to wait (with the existing timeout) for the real logout
message.
|
|
|
|
|
|
dullahan_host.exe pops up late in the session - not clear this will remove the popup but it might and it will hopefully have our publisher info on it vs 'Unknown'
|
|
|
|
attenuation
|
|
|
|
|
|
rely on the SDK setup.
Remove old dinput8 import library as it is not needed
|
|
and the 8.1 SDK) DirectX is included in the SDK and does not need any
special detection logic.
|
|
|
|
tryPushFrontFor() is pushFront() with a std::chrono::duration timeout.
|
|
Making coproc scoped to the for loop will make sure the destructor gets
called every loop iteration. Keeping it's scope outside the for loop
means the pointer keeps valid till the next assigment that happens
inside pop_wait_for when it gets assigned a new value.
Triggering the dtor inside pop_wait_for can lead to deadlock when inside
the dtor a coroutine tries to call enqueueCoprocedure (this happens).
enqueueCoprocedure then will try to grab the lock for try_push but this
lock is still held by pop_wait_for.
|
|
|
|
This reverts commit bf8aea5059f127dcce2fdf613d62c253bb3fa8fd.
Try boost::fibers::buffered_channel again with Boost 1.72.
|
|
|
|
|
|
following promotion of DRTVWR-460
|
|
sub-components
|
|
The observed crash was due to sharing a stateful global resource (the global
LLMessageSystem instance) between different tasks. Specifically, a coroutine
sets its mMessageReader one way, expecting that value to persist until it's
done with message parsing, but another coroutine sneaks in at a suspension
point and sets it differently.
Introduce LockMessageReader and LockMessageChecker classes, which must be
instantiated by a consumer of the resource. The constructor of each locks a
coroutine-aware mutex, so that for the lifetime of the lock object no other
coroutine can instantiate another.
Refactor the code so that LLMessageSystem::mMessageReader can only be modified
by LockMessageReader, not by direct assignment. mMessageReader is now an
instance of LLMessageReaderPointer, which supports dereferencing and
comparison but not assignment. Only LockMessageReader can change its value.
LockMessageReader addresses the use case in which the specific mMessageReader
value need only persist for the duration of a single method call. Add an
instance in LLMessageHandlerBridge::post().
LockMessageChecker is a subclass of LockMessageReader: both lock the same
mutex. LockMessageChecker addresses the use case in which the specific
mMessageReader value must persist across multiple method calls. Modify the
methods in question to require a LockMessageChecker instance. Provide
LockMessageChecker forwarding methods to facilitate calling the underlying
LLMessageSystem methods via the LockMessageChecker instance.
Add LockMessageChecker instances to LLAppViewer::idleNetwork(), a couple cases
in idle_startup() and LLMessageSystem::establishBidirectionalTrust().
|
|
Specifically:
LLCoros::Mutex means boost::fibers::mutex
LLCoros::LockType means std::unique_lock<boost::fibers::mutex>
LLCoros::ConditionVariable means boost::fibers::condition_variable
LLCoros::cv_status means boost::fibers::cv_status
So as not to drag in all of boost::fibers::mutex.hpp or condition_variable.hpp
for each consumer of llcoros.h, instead #define LLCOROS_MUTEX_HEADER and
LLCOROS_CONDVAR_HEADER. Those who need them can #include the relevant macro.
Update llcond.h and llthreadsafequeue.h accordingly.
|
|
for compatibility with Python llbase.llsd.parse().
The Python parse() currently requires uppercase hex digits for b16"hex"
coding; lowercase hex digits cause it to raise LLSDParseError.
|
|
First, the signature classname(const T*) was wrong: that function could only
accept a pointer to const T. The expression classname(someptr) where someptr
was a pointer to non-const SomeType displayed "SomeType*" because it could
only match classname(const T&), where T was SomeType*.
classname(T* const) is what we should have written, meaning "const pointer to
T" rather than "pointer to const T."
Second, the previous implementation failed to handle the case in which the
pointer was nullptr.
|
|
LLSDNotationFormatter (also LLSDNotationStreamer that uses it, plus
operator<<(std::ostream&, const LLSD&) that uses LLSDNotationStreamer) is most
useful for displaying LLSD to a human, e.g. for logging. Having the default
dump raw binary bytes into the log file is not only suboptimal, it can
truncate the output if one of those bytes is '\0'. (This is a problem with the
logging subsystem, but that's a story for another day.)
Use OPTIONS_PRETTY_BINARY wherever there is a default LLSDFormatter
::EFormatterOptions argument.
Also, allow setting LLSDFormatter subclass boolalpha(), realFormat() and
format(options) using optional constructor arguments. Naturally, each subclass
that supports this must accept and forward these constructor arguments to its
LLSDFormatter base class constructor.
Fix a couple bugs in LLSDNotationFormatter::format_impl() for an LLSD::Binary
value with OPTIONS_PRETTY_BINARY:
- The code unconditionally emitted a b(len) type prefix followed by either raw
binary or hex, depending on the option flag. OPTIONS_PRETTY_BINARY caused it
to emit "0x" before the hex representation of the data. This is wrong in
that it can't be read back by either the C++ or the Python LLSD parser.
Correct OPTIONS_PRETTY_BINARY formatting consists of b16"hex digits" rather
than b(len)"raw bytes".
- Although the code did set hex mode, it didn't set either the field width or
the fill character, so that a byte value less than 16 would emit a single
digit rather than two.
Instead of having one LLSDFormatter::format() method with an optional options
argument, declare two overloads. The format() overload without options passes
the mOptions data member to the overload accepting options.
Refactor the LLSDFormatter family, hoisting the recursive format_impl() method
(accepting level) to a pure virtual method at LLSDFormatter base-class level.
Most subclasses therefore need not override either base-class format() method,
only format_impl(). In fact the short format() overload isn't even virtual.
Consistently use LLSDFormatter::EFormatterOptions enum as the options
parameter wherever such options are accepted.
|
|
|
|
|
|
|
|
Having it on just one source file was frustrating because the project build
failed before it reached the one source file with the switch.
|
|
|
|
First, get rid of ancient cruft in the find_path() calls: on a 64-bit system,
"$ENV{PROGRAMFILES}" expands to the 64-bit 'Program Files' directory rather
than the 32-bit 'Program Files (x86)' directory, and none of the ancient cruft
would be found there anyway.
Empirically, find_path(dxdiag.h) is able to find the file using environment
variables (INCLUDE from VS variables?), so it doesn't need the specific
pathnames coded into that call.
Once we find DIRECTX_INCLUDE_DIR, don't immediately insert it into
include_directories: we've had troubles with incompatible Windows SDK versions
(compile errors in Microsoft header files!) when DIRECTX_INCLUDE_DIR preceded
the Windows SDK directory in the include path.
The DIRECTX_FIND_QUIETLY logic seemed backwards: the message(STATUS) output was
emitted only when DIRECTX_FIND_QUIETLY was false. Reverse that.
The ancient cruft in find_path(dxguid.lib) was causing it to find the wrong
(very old) DirectX library. Remove ancient cruft. But empirically, without
that, even once we've found DIRECTX_INCLUDE_DIR, CMake could not implicitly
find dxguid.lib. If the DirectX directory hierarchy were structured as
.../version/Include and .../version/Lib, a relative pathname would have been
sufficient hint. Unfortunately it's structured as .../Include/version and
.../Lib/version, so a relative pathname would have to include the specific
version. Instead, replace "/Include/" with "/Lib/". But even then, we have to
drill down to the architecture-specific subdirectory based on ADDRESS_SIZE.
|
|
for new llsd_clone(), llsd_shallow() functions.
|
|
|
|
|
|
|
|
|
|
following promotion of DRTVWR-500
|
