| Age | Commit message (Collapse) | Author |
|---|
|
|
|
branch. Cloned canonical viewer into DRTVWR-519, copied over the files that changed from DRTVWR-506-simple and pushed back. Once I am satisfied everything is correct, DRTVWR-506-simple will be removed
|
|
# Conflicts:
# indra/cmake/DirectX.cmake
# indra/newview/llviewerparcelmedia.cpp
# indra/newview/viewer_manifest.py
|
|
The llappviewerwin32.cpp create_console() function called by
LLAppViewerWin32::initConsole() used to assign *stderr = *(new FILE* value),
and so forth for stdout and stdin. That dubious tactic no longer works with
the new Windows CRT introduced with VS 2015. freopen_s() works much better.
|
|
(cherry picked from commit 0b61150e698537a7e42a4cdae02496da500399d9)
|
|
There are separate stanzas in llappviewerwin32.cpp's create_console() function
for each of STD_INPUT_HANDLE, STD_OUTPUT_HANDLE and STD_ERROR_HANDLE. SL-13361
wants to add more code to each. Factor out new local set_stream() function and
make create_console() call it three times.
(cherry picked from commit 13b78a0c5a788c617866e3530c65dae616e6520f)
|
|
The Microsoft _open_osfhandle() opens a HANDLE to produce a C-style int file
descriptor suitable for passing to _fdopen(). We used to cast the HANDLEs
returned by GetStdHandle() to long to pass to _open_osfhandle(). Since HANDLE
is an alias for a pointer, this no longer works.
Fortunately _open_osfhandle() now accepts intptr_t, so we can change the
relevant GetStdHandle() calls. (But why not simply accept HANDLE in the first
place?)
|
|
|
|
|
|
The whole remaining difference between llifstream and std::ifstream is that
the former handles UTF-8 coded pathnames. Microsoft's implementation of the
latter does not.
|
|
|
|
|
|
|
|
MAINT-8991: only escape log message characters once, add unit test
remove extra log line created by LL_ERRS
document that tags may not contain spaces
|
|
Also use the LLOSInfo information for platform rather than simply Windows32 or
Windows64.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It is not obvious whether the BugsplatMac attachment API even supports
multiple file attachments. I've contacted BugSplat support.
|
|
Direct BugSplat to send crash reports without prompting, on both Windows and
Mac.
Add a mechanism by which code called after LL_ERRS() can retrieve the fatal
log message string. (How did the crash logger extract that for Linden crash
logging?)
Add that fatal message to crash reports on Windows. But as BugsplatMac is
engaged only on the run _after_ the crash, we no longer have that message in
memory.
Also add user name and region location to Windows crash reports. On Mac, (a)
we don't have the information from the previous run and (b) BugsplatMac
doesn't provide an API to attach that information to the crash report.
Add Mac logging to indicate the success or failure of sending the crash
report. Add Windows logging to indicate we're about to send.
|
|
The Breakpad symbol-file upload in the viewer's build.sh was failing on
BugSplat builds since we weren't generating Breakpad symbol files. That upload
was conditional on RELEASE_CRASH_REPORTING, so my first approach was to set
RELEASE_CRASH_REPORTING=OFF for BugSplat builds. Unfortunately that symbol
also propagates down into C++ compiles, and in llappviewerwin32.cpp, both
Breakpad and BugSplat crash reporting is conditional on it. So that change
inadvertently turned off the C++ logic to engage BugSplat.
Stop forcing RELEASE_CRASH_REPORTING=OFF for BugSplat builds. Instead, make
the Breakpad symbol-file upload check the BUGSPLAT_DB variable as well.
Add #pragma messages to llappviewerwin32.cpp so we can detect whether it's
being built for Breakpad or BugSplat or neither.
|
|
It might point to an uninitialized LLDir, but that's a whole separate problem,
one that wouldn't be detected by checking for nullptr. If we hit that, time to
change to an LLSingleton.
|
|
|
|
|
|
|
|
On TeamCity, set BUGSPLAT_DB from build-secrets.
Use the presence of $BUGSPLAT_DB, rather than a new CMake BUGSPLAT option, to
control whether CMake searches for BugSplat -- and passes LL_BUGSPLAT into C++.
When BUGSPLAT_DB is present, make viewer_manifest.py set "BugSplat DB" in
build_data.json, and "BugsplatServerURL" in Mac Info.plist.
Make llappviewerwin32.cpp read "BugSplat DB" from build_data.json.
Add placeholders for Mac hooks to suppress BugSplat prompt and send
SecondLife.log.
|
|
BugSplat has no business introducing a new C++ API based on classic-C function
pointers without even a generic pass-through user data pointer!
|
|
|
|
Use WSTRINGIZE(), LL_TO_WSTRING(), wstringize() to produce required wide
strings. Use a lambda for callback that sends log file; use LLDir, if set, to
find the log file.
Introduce BUGSPLAT CMake variable to allow suppressing BugSplat.
Make BUGSPLAT CMake variable set LL_BUGSPLAT for C++ compilations.
Set viewer version macros on llappviewerwin32.cpp, llappviewerlinux.cpp and
llappdelegate-objc.mm -- because BugSplat needs the viewer version data, and
because the macOS BugSplat hook is engaged in an Objective-C++ function we
override in the app delegate.
|
|
Currently this check should work on windows and linux.
|
|
|
|
|
|
|
|
|
|
LLWinDebug, though an LLSingleton, had (and required explicit calls to)
special init() and cleanup() methods. Kitty Barnett points out that the
cleanup() method was actually being called after LLSingletonBase::deleteAll(),
requiring resurrection of the deleted LLWinDebug, which sometimes led to
crashes. (Resurrecting deleted LLSingletons is always suspect.)
Change LLWinDebug::init() and cleanup() to the conventional initSingleton()
and cleanupSingleton() methods. This eliminates the need to make special
method calls at all. In particular, cleanupSingleton() will be called by the
existing LLSingletonBase::cleanupAll() call near viewer shutdown.
We retain the early LLWinDebug::instance() call, which implicitly initializes
the LLWinDebug instance, because evidently we want that initialized early. But
we no longer require a separate init() call.
|
|
|
|
|
|
|
|
|
|
overrides DPI compatibility option
|
|
The LLApp API used to consist of init(), mainLoop(), cleanup() methods. This
makes sense -- but on Mac that structure was being subverted. The method
called mainLoop() was in fact being called once per frame. There was
initialization code in the method, which (on Mac) needed to be skipped with an
already-initialized bool. There was a 'while' loop which (on Mac) needed to be
turned into an 'if' instead so the method would return after every frame.
Rename LLApp::mainLoop() to frame(). Propagate through subclasses LLAppViewer
and LLCrashLogger. Document the fact that frame() returns true to mean "done."
(This was always the case, but had to be inferred from the code.)
Rename the Mac Objective-C function mainLoop to oneFrame. Rename the C++ free
function it calls from runMainLoop() to pumpMainLoop(). Add comments to
llappdelegate-objc.mm explaining (inferred) control flow.
Change the Linux viewer main() and the Windows viewer WINMAIN() from a single
LLAppViewer::mainLoop() call to repeatedly call frame() until it returns true.
Move initialization code from the top of LLAppViewer::frame() to the init()
method, where it more properly belongs. Remove corresponding
mMainLoopInitialized flag (and all references) from LLAppViewer.
Remove 'while (! LLApp::isExiting())' (or on Mac, 'if (! LLApp::isExiting())')
from LLAppViewer::frame() -- thus unindenting the whole body of the 'while'
and causing many lines of apparent change. (Apologies to reviewers.)
There are four LLApp states: APP_STATUS_RUNNING, APP_STATUS_QUITTING,
APP_STATUS_STOPPED and APP_STATUS_ERROR. Change LLAppViewer::frame() return
value from (isExiting()) (QUITTING or ERROR) to (! isRunning()). I do not know
under what circumstances the state might transition to STOPPED during a
frame() call, but I'm quite sure that if it does, we don't want to call
frame() again. We only want a subsequent call if the state is RUNNING.
Also rename mainLoop() method in LLCrashLogger subclasses
LLCrashLoggerWindows, LLCrashLoggerMac, LLCrashLoggerLinux. Of course it's
completely up to the frame() method whether to yield control; none of those in
fact do. Honor protocol by returning true (frame() is done), even though each
one's main() caller ignores the return value.
In fact LLCrashLoggerWindows::mainLoop() wasn't using the return protocol
correctly anyway, returning wParam or 0 or 1 -- possibly because the return
protocol was never explicitly documented. It should always return true: "I'm
done, don't call me again."
|
|
|
|
|
|
|
|
|
|
|
|
|
