| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Useful when installed as shared libraries, so other viewer executables
can share these libraries.
|
|
|
|
Even though the account was logged in, it would get stuck at getting
region handshake. The problem was because the viewer wasn't getting the
acknowledgement to the successfully sent UseCircuitCode message. I
compared the message data, and it differed (from Linux) on the byte
order of the Code variable (the SessionID & agent ID were right). The
bytes sent to the network weren't reversed (and I was on an Intel
processor).
|
|
Otherwise we'd get this.
error: declaration of anonymous struct must be a definition
struct Status
^
indra/llcommon/llprocess.h:284:2: warning:
declaration does not declare anything [-Wmissing-declarations]
|
|
|
|
|
|
|
|
|
|
Relies on sysctl, like on Darwin, and on parsing a file, like on Linux,
except the file would be /var/run/dmesg.boot.
|
|
Since C++11, NULL is promoted to nullptr on some BSD platforms. This is
very problematic when used with Boost. At times it would fail during
compile-time. What's worse is if it passes compile-time, but then crash
during run-time, for example when some condition is to be checked for its
truth, when then it would be compared to a nullptr.
|
|
|
|
I had added this to CMAKE_CXX_FLAGS in 00-Common before, and only when
the compiler was Clang. But it turned out that GCC was treating them as
errors too, that the addition would need to be applied to all compilers.
So I prefer to put it here in llcommon with the scope set to PUBLIC
cause the errors would show up again when compiling other LL libraries
if the scope is set to something else.
|
|
in order to get rid of errors complaining that size_t was not declared
in the scope.
|
|
|
|
improvements can lead to perceived inventory loss due to cache corruption"
This reverts commit cf692c40b0b9f8d0d04cd10a02a84e3f697a2e99.
|
|
|
|
|
|
# Conflicts:
# doc/contributions.txt
# indra/llcharacter/llkeyframemotion.cpp
# indra/newview/llfilepicker.cpp
|
|
|
|
|
|
Newer C++ compilers have different semantics around LLSDArray's special copy
constructor, which was essential to proper LLSD nesting. In short, we can no
longer trust LLSDArray to behave correctly. Now that we have variadic
functions, get rid of LLSDArray and replace every reference with llsd::array().
|
|
|
|
|
|
# Conflicts:
# indra/integration_tests/llui_libtest/CMakeLists.txt
# indra/newview/llfloateravatarrendersettings.cpp
|
|
|
|
# Conflicts:
# indra/cmake/CMakeLists.txt
# indra/newview/skins/default/xui/es/floater_tools.xml
|
|
lead to perceived inventory loss due to cache corruption
|
|
# Conflicts:
# indra/cmake/Copy3rdPartyLibs.cmake
# indra/cmake/FindOpenJPEG.cmake
# indra/cmake/OpenJPEG.cmake
# indra/integration_tests/llui_libtest/CMakeLists.txt
# indra/newview/CMakeLists.txt
|
|
As it happens, the change in the LLUUID::combine() algorithm introduced by one
of my previous commits is causing invalid assets creation (seen with
some clothing items, such as Shape and Universal types); obviously, the server
is using the old algorithm for UUID validation purpose of these assets.
This commit reverts LLUUID::combine() code to use LLMD5.
|
|
# Conflicts:
# indra/llcommon/llsdserialize.cpp
# indra/llcommon/llsdserialize.h
# indra/newview/llfilepicker.h
# indra/newview/llfilepicker_mac.h
# indra/newview/llfilepicker_mac.mm
|
|
# Conflicts:
# doc/contributions.txt
# indra/cmake/Copy3rdPartyLibs.cmake
# indra/cmake/FindOpenJPEG.cmake
# indra/cmake/OpenJPEG.cmake
# indra/integration_tests/llui_libtest/CMakeLists.txt
# indra/newview/CMakeLists.txt
|
|
|
|
|
|
|
|
|
|
speed matters. (#64)
This commit adds the HBXX64 and HBXX128 classes for use as a drop-in
replacement for the slow LLMD5 hashing class, where speed matters and
backward compatibility (with standard hashing algorithms) and/or
cryptographic hashing qualities are not required.
It also replaces LLMD5 with HBXX* in a few existing hot (well, ok, just
"warm" for some) paths meeting the above requirements, while paving the way for
future use cases, such as in the DRTVWR-559 and sibling branches where the slow
LLMD5 is used (e.g. to hash materials and vertex buffer cache entries), and
could be use such a (way) faster algorithm with very significant benefits and
no negative impact.
Here is the comment I added in indra/llcommon/hbxx.h:
// HBXXH* classes are to be used where speed matters and cryptographic quality
// is not required (no "one-way" guarantee, though they are likely not worst in
// this respect than MD5 which got busted and is now considered too weak). The
// xxHash code they are built upon is vectorized and about 50 times faster than
// MD5. A 64 bits hash class is also provided for when 128 bits of entropy are
// not needed. The hashes collision rate is similar to MD5's.
// See https://github.com/Cyan4973/xxHash#readme for details.
|
|
|
|
|
|
|
|
Fixes folders being invidible (missing arrange)
Fixes sroll to target not working reliably
|
|
D577 should have picked part of the changes from contribute branch, picking up the rest for the sake of branch specific crash fixes
|
|
|
|
# Conflicts:
# autobuild.xml
# indra/newview/llagent.cpp
# indra/newview/llimview.cpp
# indra/newview/llimview.h
# indra/newview/llinventoryfunctions.cpp
# indra/newview/llpanelmediasettingsgeneral.cpp
# indra/newview/pipeline.cpp
|
|
branches (#47)
Revert part of "DRTVWR-575: Address review comments on Xcode 14.1 type tweaks."
Crash was reproduced when assigning areastr to llsd, but likely present in other cases of assigning ui strings to llsd (instead of going for lluistring's result directly copy constructor was engaged and either copy or original crashed due to invalid pointers, copy shouldn't have been created).
|
|
|
|
|
|
One could argue that passing a negative index to an LLSD array should do
something other than shrug and reference element [0], but as that's legacy
behavior, it seems all too likely that the viewer sometimes relies on it.
This specific problem arises if the index passed to operator[]() is negative
-- either with the previous Integer parameter or with size_t (which of course
reinterprets the negative index as hugely positive). The non-const
ImplArray::ref() overload checks parameter 'i' and, if it appears negative,
sets internal 'index' to 0.
But in the next stanza, if (index >= existing size()), it calls resize() to
scale the internal array up to one more than the requested index. The trouble
is that it passed resize(i + 1), not the adjusted resize(index + 1).
With a requested index of exactly -1, that would pass resize(0), which would
result in the ensuing array[0] reference being invalid.
With a requested index less than -1, that would pass resize(hugely positive)
-- since, whether operator[]() accepts signed LLSD::Integer or size_t,
resize() accepts std::vector::size_type. Given that the footprint of an LLSD
array element is at least a pointer, the number of bytes required for
resize(hugely positive) is likely to exceed available heap storage.
Passing the adjusted resize(index + 1) should defend against that case.
|
|
The compiler was deducing an unsigned type for the difference (U64 desired
microseconds - half KERNEL_SLEEP_INTERVAL_US). When the desired sleep was less
than that constant, the difference went hugely positive, resulting in a very
long snooze.
Amusingly, forcing that U64 result into an S32 num_sleep_intervals worked only
*because* of integer truncation: the high-order bits were discarded, resulting
in a negative result as intended.
Ensuring that both integer operands are signed at the outset, though, produces
a more formally correct result.
|
|
# Conflicts:
# doc/contributions.txt
# indra/newview/llappviewer.cpp
# indra/newview/skins/default/colors.xml
|
