Open sl-service-account opened 8 years ago
Whirly Fizzle commented at 2016-05-13T00:35:16Z
I thought the bake fail bug was fixed for me - but for some reason it's happening to me every login today on the new QuickGraphics-RC Second Life 4.0.5.315117 (Second Life Release).
2016-05-13T00:23:56Z WARNING:#CoreHttp LLCore::HttpPolicy::stageAfterCompletion: HTTP request 172837A0 failed after 0 retries. Reason: Bad Request (Http_400)
2016-05-13T00:23:56Z WARNING: LLCoreHttpUtil::HttpCoroHandler::onCompleted:
--------------------------------------------------------------------------
Error[Http_400] cannot access url 'https://sim8922.agni.lindenlab.com:12043/cap/3df16ab7-b234-f8af-367f-20a8f87e6080' because Bad Request
--------------------------------------------------------------------------
2016-05-13T00:23:56Z WARNING:#Avatar LLAppearanceMgr::serverAppearanceUpdateCoro: Appearance Failure. server responded with "Cof Version Mismatch: 161259 != 161263"
2016-05-13T00:23:56Z WARNING:#Avatar LLAppearanceMgr::serverAppearanceUpdateCoro: Server expected 161263 as COF version
2016-05-13T00:23:56Z WARNING:#Avatar LLAppearanceMgr::serverAppearanceUpdateCoro: Bake retry count exceeded!
Second Life 4.0.5.315117 (Second Life Release)
Release Notes
You are at 89.9, 115.0, 22.0 in Testylvania Sandbox located at sim8922.agni.lindenlab.com (216.82.41.98:12035)
SLURL: http://maps.secondlife.com/secondlife/Testylvania%20Sandbox/90/115/22
(global coordinates 332,634.0, 306,291.0, 22.0)
Second Life Server 16.04.21.314319
Error fetching server release notes URL.
CPU: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz (3491.93 MHz)
Memory: 16268 MB
OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 750/PCIe/SSE2
Windows Graphics Driver Version: 10.18.0013.6472
OpenGL Version: 4.5.0 NVIDIA 364.72
J2C Decoder Version: KDU v7.2
Audio Driver Version: FMOD Ex 4.44.31
LLCEFLib/CEF Version: 1.5.3-(CEF-WIN-3.2526.1347-32)
Voice Server Version: Vivox 4.6.0017.22050
Packets Lost: 97/14,022 (0.7%)
I hate this bug :/
Whirly Fizzle commented at 2016-05-13T00:50:33Z, updated at 2016-05-13T00:53:04Z
Whirly Fizzle commented at 2016-05-19T21:17:54Z, updated at 2016-05-19T21:19:17Z
Still reproduces on http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/clefable/rev/315545/index.html
Logged in.
Saw in logs the appearance errors right from login.
Waited a few mins then changed into default female avatar: Develop -> Avatar -> Character Tests -> Test female.
This was the result: http://prnt.sc/b63bpu
Bake remained stuck on the old bake & several attachments (shoes, one earing & one mesh eye) from the old outfit were not removed.
Log attached - Whirly3.log
The release of the recent maintenance update 4.0.4 (314579) included some fixes for avatar appearance updates, that should fix stale appearance update requests. These don't appear to have any effect though, as appearance updates are still broken due to version mismatches of the local COF version and the COF version the server expects.
Original cause is still the handling of attachments being rezzed during login, leading to a COF version mismatch. These will consequently produce appearance update failures and the log gets spammed with according error messages, as the appearance update request coroutine appears to get invoked multiple times (for each attachment rezzed):
Above excerpt from the viewer log file was from a session when I logged in my avatar with the Second Life viewer for the first time. At the end, I tried to detach a wearable item, which of course didn't produce any visible effect -> appearance was stuck.
This might also be caused by the fact that the re-request doesn't work as intended. This is the relevant code in llappearancemgr.cpp which handles the case of a bad appearance update request:
If you look at the comment, it says the request should be re-send with the corrected COF version. The corrected (= expected) COF version is then extracted from the response and printed out before the re-request is issued. But that is apparently all - there is no correction happening at all. Shouldn't the local COF version (and possibly gAgentAvatarp->mLastUpdateRequestCOFVersion and gAgentAvatarp->mLastUpdateReceivedCOFVersion) get set to the expected version first before issuing the request again?
Attachments
Links
Related
Original Jira Fields
| Field | Value | | ------------- | ------------- | | Issue | BUG-11929 | | Summary | Appearance update is STILL broken after recent changes in 4.0.4 (314579) | | Type | Bug | | Priority | Unset | | Status | Accepted | | Resolution | Accepted | | Reporter | Ansariel Hiller (ansariel.hiller) | | Created at | 2016-05-11T09:13:43Z | | Updated at | 2016-09-17T19:14:13Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2016-05-12T19:35:15.598-0500', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'System': 'SL Viewer', 'Target Viewer Version': 'viewer-development', 'What just happened?': 'Filling in...', 'What were you doing when it happened?': '-', 'What were you expecting to happen instead?': '-', } ```