summaryrefslogtreecommitdiff
path: root/indra/newview/llwatchdog.cpp
AgeCommit message (Collapse)Author
2021-09-28Revert "Merge branch 'c++17' into DRTVWR-522-maint"Andrey Lihatskiy
This reverts commit 203ea3a70a775a09cbbffb1740ab7c58f1780baa, reversing changes made to 8e3f0778863a5aa337d1148a243ea91d238a8ac5. # Conflicts: # indra/newview/llmachineid.cpp
2021-08-27Merge branch 'c++17' into DRTVWR-522-maintAndrey Lihatskiy
2021-05-07SL-15241: Tweak viewer sources to permit compiling on Mac with C++17.Nat Goodspeed
2020-08-24SL-10297 merged 6.4.7Oz Linden
2020-03-25DRTVWR-476: Defend against late ~LLWatchdogTimeout() calls.Nat Goodspeed
LLAppViewer's heap LLWatchdogTimeout might be destroyed very late -- as late as in LLAppViewer's destructor. By that time, LLAppViewer::cleanup() has already called LLSingletonBase::deleteAll(), destroying the LLWatchdog LLSingleton instance. But LLWatchdogTimeout isa LLWatchdogEntry, and ~LLWatchdogEntry() calls stop(), and stop() tries to remove that instance from LLWatchdog, thus inadvertently resurrecting the deleted LLWatchdog. Which is pointless because the resurrected LLWatchdog has never heard of the LLWatchdogTimeout instance trying to remove itself. Defend LLWatchdogEntry::stop() against the case in which LLWatchdog has already been deleted.
2019-03-02convert to an explicit USE_BUGSPLAT switch in cmake, revise LL_ERRS approachOz Linden
2019-01-16SL-10297: Modify LL_ERRS and other deliberate crashes to avoid a common ↵Oz Linden
stack frame
2019-01-14SL-10291 Replace apr_mutex with standard C++11 functionalityandreykproductengine
2016-03-16merge changes for DRTVWR-417Oz Linden
2015-12-16MAINT-906 expiration time gets zeroesandreykproductengine
2015-11-10remove execute permission from many files that should not have itOz Linden
2013-08-09second phase summer cleaningRichard Linden
replace llinfos, lldebugs, etc with new LL_INFOS(), LL_DEBUGS(), etc.
2013-06-05merge with viewer-releaseRichard Linden
2013-03-29Update Mac and Windows breakpad builds to latestGraham Madarasz
2011-07-15STORM-1355 Memory issues from UI for very large groupsRoxie Linden
This change is not guaranteed to fix this issue as the issue is difficult to repro, but there was a sketchy case group member responses come back from the simulator in message packets. For very large numbers of members, there may be a large number of packets received. The member data is placed in a structure of type LLGroupMgrGroupData, based on the group id. The problem is, if the user refreshes the group before the entire contents of the previous request comes back, response packets from the previous request will be intermingled with the responses from the refresh. Both the request call and the response handler would create the group data structure, if the structure wasn't already there. There may be a case where a response from the previous request causes creation of the group data, populating it with the contents of the response, and the responses from the second request would use that group data structure. Also, cleaned up some comments and variable names to be consistent
2010-08-13Change license from GPL to LGPL (version 2.1)Oz Linden
2009-01-08Result of svn merge -r107256:107258 ↵Aaron Brashears
svn+ssh://svn/svn/user/phoenix/license_2009_merge into trunk. QAR-1165
2008-12-23QAR-1142 merging 1.22 RC0-RC4 changes.Mark Palange
svn merge -c 106471 svn+ssh://svn.lindenlab.com/svn/linden/qa/viewer_1-22-106055_merge
2008-06-06QAR-650 - Viewer RC 9 merge -> release (post cmake)Steven Bennetts
merge release@88802 Branch_1-20-Viewer-2-merge-1@89178 -> release
2008-05-14Result of svn merge -r 87455:87538 $SVN/branches/tulla/vc3-merge .Eric Tulla
Passed QA as part of QAR-491.