[opensource-dev] Miscellaneous bad code in llviewerobject.cpp

[John Nagle]

I've been looking for the "half-unsit" region crossing bug,
adding debug code to llviewerobject.  Something is going wrong
in reparenting, but I haven’t been able to isolate it yet.

Looking in there, I've found some code that's wrong, but
probably not causing trouble.

- Two possible buffer overflows. Reported to LL, being treated as
a security issue.

- Unchecked downcasts on polymorphic types.  Those are
risky. There's at least one place where an unexpected message
from the sim will cause an invalid downcast. That's
been reported to LL. Newer fixes use dynamic_cast, but
some of the older ones don't.  There's one place
where there's an unchecked downcast followed by a
test for null. That's undefined behavior on a class with
multiple inheritance. It seems to work because it's a
downcast on the first parent class, but that's an
accident of the C++ implementation.

- Can this test, around line 1650, ever return true?

// BUG: this is a bad assumption once border crossing is alowed
 if (  (parent_id == cur_parentp->mLocalID)
&&(update_type == OUT_TERSE_IMPROVED))

If update type is OUT_TERSE_IMPROVED, there can't be a parent id,
I think. Only full updates have parent info. So that path should
never be taken. Should the "&&" be a "||"?

None of this is the region crossing bug; it's just stuff I am
finding as I look for that.

(Does anybody still read this list?)

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] compiling viewer-release on linux

[John Nagle]

   Here's how I currently compile successfully on Linux.
This builds the development version 5.1.9, not the
release version.

Install all prerequisites per
http://wiki.phoenixviewer.com/fs_compiling_firestorm_64bit_ubuntu

Create a working directory for the version you're building.

 hg clone http://hg.phoenixviewer.com/phoenix-firestorm-lgpl
 hg clone https://hg.phoenixviewer.com/fs-build-variables/
 export CC=/usr/bin/gcc-4.9
 export CXX=/usr/bin/g++-4.9
 export AUTOBUILD_VARIABLES_FILE=`readlink -f 
fs-build-variables/variables`
 cd phoenix-firestorm-lgpl
 /usr/local/bin/autobuild configure -A 64 -c ReleaseFS_open

 nice /usr/local/bin/autobuild build -A 64 -c ReleaseFS_open

That builds fine on Ubuntu 16.04 LTS.  If you change something
in the source, just return the last step to rebuild.

If you want it to not crash with the 5-channel texture bug,
apply the patch at

https://jira.phoenixviewer.com/browse/FIRE-22652

LL's fix for that isn't merged in yet.

I've been running this version for about a month now without
trouble.


___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] HTTP asset fetching will soon be mandatory

[John Nagle]

On 10/30/2018 02:42 AM, Henri Beauchamp wrote:
> On Mon, 29 Oct 2018 17:59:13 -0400, Oz Linden (Scott Lawrence) wrote:
> 
>> On 2018-10-19 09:52 , Henri Beauchamp wrote:
>>
>>> My viewer has long been updated to make use of the newest HTTP fetching
>>> capabilities, but it also implements an automatic fallback to UDP fetches
>>> when HTTP ones fail (i.e. a texture failing to be served via HTTP is
>>> automatically re-requested using UDP).
>>
>> Better to requeue the request to HTTP after a suitable backoff (unless
>> of course you get a error that indicates that a retry would not work).
> 
> The fallback happens only for unrecoverable errors, of course (for other
> errors the HTTP retry policy is used)...

 I see 404 errors for capabilities frequently in Firestorm logs.
This shows up at region crossings as the viewer is fetching info
from the sim being entered. This may be a race condition, and
retrying may help.  Dropping to UDP probably isn't helpful.

 Asset fetches sometimes fail with 5xx errors indicating
problems with the CDN system caches.  When you ask the CDN
for an asset, you're really talking to (I think) a Nginx cache
server, which requests the asset from AWS. If the cache to AWS
request isn't filled quickly, you get a bogus error from the
cache system.  I've seen this occasionally.

 So I'd suggest retrying a few more times, at maybe 1 second,
on what look like hard errors on any URL that the sim gives you.
They're supposed to be valid URLs, after all.

John Nagle
Animats resident


___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Windows ReleaseOS build unable to load textures

[John Nagle]

Is this related to

https://jira.phoenixviewer.com/browse/FIRE-22342

The problem there was with 5-channel images.  SL has a few of those;
in some old format, eyelash length was encoded as an extra JPEG
color channel.  Those resulted in crashes where the fast cache
decoder didn't have a case for a 5-level texture.

That was not fixed in Firestorm because LL had a fix in their code
which was not yet integrated into Firestorm. See JIRA. Could it be
that some combination of the fixes is clashing?

It would be nice to get this fixed so building from source would
Just Work again.


On 2/11/19 2:30 AM, Jonathan Welch wrote:
> Graham worked on a fix for this which is an improvement but still has 
> some loading issues:
> 
> 
> https://bitbucket.org/lindenlab/viewer-tco
> 
> You'll need to build it with -DUSE_OPENJPEG:BOOL=TRUE to test that path 
> anyway, the TC-built version assumes KDU.
> 
> On Mon, Feb 11, 2019, 5:15 AM Kadah   wrote:
> 
> I'm working on a thing (some of you know what) and I've run in to a
> rather annoying issue that's sunk most of the day as it was starting to
> make testing difficult.
> 
> None of my ReleaseOS viewer-release builds are able to load textures.
> I've found that it's fine if I patch in KDU. While that is a
> workaround,
> it would be nice to know what I'm doing that makes OpenJPEG fail,
> assuming it does work at all.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] SL server issues in the past 4 months

[John Nagle]

On 4/10/19 4:27 AM, Henri Beauchamp wrote:
> In the mean time, I managed to diagnose the rebake issue and fixed it:
> what I found out could, perhaps, also be a hint about what happens for
> failed TPs.
> 
> The problem was a race condition (as it is often the case in the
> server/viewer communication): my workaround for derezzing attachments
> triggered a rebake in the arrival sim, but I did not check whether the
> capabilities for that sim were received or not; this did not cause any
> issue before last week (i.e. rebaking with old (cached, in my viewer)
> capabilities URIs did not matter), but it does now (whether it is the
> result of a changed timing, algorithm or policy on the server side is
> of course unknown to me).
> 
> In my new code, I simply flag the rebake as needed and now actually
> perform it only once the capabilities for the new agent region are
> received, and everything works like a charm (well, not fully, since that
> workaround should not even be needed in the first place, and the bogus
> kill-objects message on agent attachments is still wrongly sent by the
> departure region).
> 
> Now, why might it be related at all with failed TPs ?... Well, if the
> capabilities are received too late, and seeing how viewers implementing
> region-Windlight are way more prone to timeouts than mine, it could
> indeed be that the viewers are attempting to use a capability that is
> not yet available, causing a timeout...

Hm. On failed teleports, I see lots of capability retrieval
failures in the Firestorm log. Like this:

2019-04-09T19:57:01Z WARNING #CoreHttp#  llcorehttp/_httppolicy.cpp(434) 
stageAfterCompletion : HTTP request 0x7f81c4f9a5f0 failed after 5 
retries.  Reason:  Not Found (Http_404)
2019-04-09T19:57:01Z WARNING #CoreHTTP# 
llmessage/llcorehttputil.cpp(282) onCompleted : Possible failure 
[Http_404] cannot POST url 
'https://sim10658.agni.lindenlab.com:12043/cap/4d310fee-b2c7-cb62-357d-0317811990e7'
 
because Not Found
2019-04-09T19:57:01Z INFO #  llcommon/llsdserialize_xml.cpp(417) parse : 
LLSDXMLParser::Impl::parse: XML_STATUS_ERROR parsing:cap not found: 
'4d310fee-b2c7-cb62-357d-0317811990e7'
2019-04-09T19:57:01Z WARNING #LLEventPollImpl# 
newview/lleventpoll.cpp(222) eventPollCoro : Canceling coroutine
2019-04-09T19:57:01Z WARNING #CoreHttp#  llcorehttp/_httppolicy.cpp(434) 
stageAfterCompletion : HTTP request 0x305e8e50 failed after 1 retries. 
Reason:  Not Found (Http_404)
2019-04-09T19:57:01Z WARNING #CoreHTTP# 
llmessage/llcorehttputil.cpp(282) onCompleted : Possible failure 
[Http_404] cannot POST url 
'https://sim10412.agni.lindenlab.com:12043/cap/d3b0c971-112d-b7c7-00d9-17dcb92b5027'
 
because Not Found
2019-04-09T19:57:01Z INFO #  llcommon/llsdserialize_xml.cpp(417) parse : 
LLSDXMLParser::Impl::parse: XML_STATUS_ERROR parsing:cap not found: 
'd3b0c971-112d-b7c7-00d9-17dcb92b5027'
2019-04-09T19:57:01Z WARNING #LLEventPollImpl# 
newview/lleventpoll.cpp(222) eventPollCoro : Canceling coroutine
2019-04-09T19:57:02Z INFO #  newview/llviewerdisplay.cpp(239) 
display_stats : FPS: 21.70
2019-04-09T19:57:02Z WARNING #CoreHttp#  llcorehttp/_httppolicy.cpp(434) 
stageAfterCompletion : HTTP request 0x40ff54b0 failed after 1 retries. 
Reason:  Not Found (Http_404)
2019-04-09T19:57:02Z WARNING #CoreHTTP# 
llmessage/llcorehttputil.cpp(282) onCompleted : Possible failure 
[Http_404] cannot POST url 
'https://sim10658.agni.lindenlab.com:12043/cap/11bb494c-1a04-24f1-8644-826273c548d8'
 
because Not Found
2019-04-09T19:57:02Z INFO #  llcommon/llsdserialize_xml.cpp(417) parse : 
LLSDXMLParser::Impl::parse: XML_STATUS_ERROR parsing:cap not found: 
'11bb494c-1a04-24f1-8644-826273c548d8'
2019-04-09T19:57:02Z WARNING #LLEventPollImpl# 
newview/lleventpoll.cpp(222) eventPollCoro : Canceling coroutine

This was from yesterday, when Oz had people from Server User Group
TPing between three mostly empty Linden sims as a test.

I've seen occasional errors like that before. That there are ever
404 errors for a cap seems wrong. The sim told the viewer to fetch
that URL directly from the sim, and then the sim didn't have it
available.

John Nagle


___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges