From nagle at animats.com Fri Sep 21 16:51:14 2018 From: nagle at animats.com (John Nagle) Date: Fri, 21 Sep 2018 16:51:14 -0700 Subject: [opensource-dev] Miscellaneous bad code in llviewerobject.cpp In-Reply-To: References: Message-ID: <0688ed1f-7204-58aa-49fd-7acfcdd7a9ed@animats.com> 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?) From nagle at animats.com Fri Sep 21 20:33:00 2018 From: nagle at animats.com (John Nagle) Date: Fri, 21 Sep 2018 20:33:00 -0700 Subject: [opensource-dev] compiling viewer-release on linux In-Reply-To: References: Message-ID: 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. From sldev at free.fr Sat Sep 22 03:18:43 2018 From: sldev at free.fr (Henri Beauchamp) Date: Sat, 22 Sep 2018 12:18:43 +0200 Subject: [opensource-dev] Miscellaneous bad code in llviewerobject.cpp In-Reply-To: <0688ed1f-7204-58aa-49fd-7acfcdd7a9ed@animats.com> References: <0688ed1f-7204-58aa-49fd-7acfcdd7a9ed@animats.com> Message-ID: <20180922121843.b50a1480afd0d84bcd71dfb2@free.fr> On Fri, 21 Sep 2018 16:51:14 -0700, John Nagle wrote: > 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. It would be nice to share your findings with us too: LL is slow to fix bugs in their code, and it will be weeks before we see the corresponding commit appear in their repository... > - Unchecked downcasts on polymorphic types. Those are risky. Many such static downcasts are there because of the LLXform -> LLPrimitive -> LLViewerObject inheritance. Since no code would create LLPrimitive or LLXForm instances outside LLVierwerObject inherited ones, the said static casts are safe, and much faster (zero overhead) than dynamic casts (+ NULL check)... But I agree that it is a bad practice and many such casts could be avoided by moving some members to the LLXform class, such as using an mIsAvatar boolean in LLXform, set by LLPrimitive inside setPCode(), then moving isAvatar() from LLPrimitive to LLXform: this way, you can test for avatar parent objects using mParent (which is a LLXform) without having to donwcast... I just implemented this for my viewer. > There's at least one place where an unexpected message from the sim > will cause an invalid downcast. That's been reported to LL. Again, it would be nice to share with us... > (Does anybody still read this list?) * raises his hand * Regards, Henri From sldev at free.fr Sat Sep 22 03:29:50 2018 From: sldev at free.fr (Henri Beauchamp) Date: Sat, 22 Sep 2018 12:29:50 +0200 Subject: [opensource-dev] compiling viewer-release on linux In-Reply-To: References: Message-ID: <20180922122950.b1aea5f567da5aed5030e859@free.fr> On Fri, 21 Sep 2018 20:33:00 -0700, John Nagle wrote: > 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 wget http://sldev.free.fr/sources/CoolVLViewer-src-1262219.tar.bz2 tar xJf CoolVLViewer-src-* cd linden/indra ./buildlinux.sh > I've been running this version for about a month now without trouble. I've been running my viewer under Linux for 11+ years without trouble ! :-D No, seriously, the question in the original message was not about help for building third party viewers under Linux, but for issues with LL's own viewers... LL would be well inspired to have a look at TPVs' build systems for Linux... Regards, Henri. From Lance.Corrimal at eregion.de Sat Sep 22 06:43:14 2018 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 22 Sep 2018 15:43:14 +0200 Subject: [opensource-dev] specifying wich python binary to use? Message-ID: <6278903.yOKPxsPXRU@kumiko> Hi, I have python 2 and python 3 installed on my system, is there a way to specify which python version autobuild should use? by default it tries python3, which fails. cheers LC From sldev at free.fr Sat Sep 22 07:00:31 2018 From: sldev at free.fr (Henri Beauchamp) Date: Sat, 22 Sep 2018 16:00:31 +0200 Subject: [opensource-dev] specifying wich python binary to use? In-Reply-To: <6278903.yOKPxsPXRU@kumiko> References: <6278903.yOKPxsPXRU@kumiko> Message-ID: <20180922160031.ca89a2b8c29b332dfb5d8a7c@free.fr> On Sat, 22 Sep 2018 15:43:14 +0200, Lance Corrimal wrote: > I have python 2 and python 3 installed on my system, is there a way to specify > which python version autobuild should use? by default it tries python3, which > fails. Depending on your distribution, you may specify (or not) which Python version is to be used when invoking 'python', with: alternatives --config python If it does not work, you may trick the build system by creating a "python" link to the python2 binary and then changing the PATH so that your link is found first. E.g. from a terminal: mkdir -p ~/bin ln -s /usr/bin/python2 ~/bin/python export PATH="$HOME/bin:$PATH" then from the same terminal, launch the build. When running any command, a script ran from that terminal will first look into the bin/ subdirectory of your home directory before looking in the rest of the $PATH directories, and "python" (linked to python2) will be found there... You may also make this a permanent feature for your login, by chanching ~/.bashrc and putting in it the same: export PATH="$HOME/bin:$PATH" For a system-wide change, create the link in /usr/local/bin and change the system-wide default PATH (usually to be found in /etc/bashrc) to list /usr/local/bin as the first directory. Henri. From Lance.Corrimal at eregion.de Sat Sep 22 07:53:27 2018 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 22 Sep 2018 16:53:27 +0200 Subject: [opensource-dev] specifying wich python binary to use? In-Reply-To: <20180922160031.ca89a2b8c29b332dfb5d8a7c@free.fr> References: <6278903.yOKPxsPXRU@kumiko> <20180922160031.ca89a2b8c29b332dfb5d8a7c@free.fr> Message-ID: <10078256.3HTcpH6jeW@kumiko> Am Samstag, 22. September 2018, 16:00:31 CEST schrieb Henri Beauchamp: > On Sat, 22 Sep 2018 15:43:14 +0200, Lance Corrimal wrote: > > I have python 2 and python 3 installed on my system, is there a way to > > specify which python version autobuild should use? by default it tries > > python3, which fails. > > Depending on your distribution, you may specify (or not) which Python > version is to be used when invoking 'python', with: alternatives --config > python > looked into that already, didn't work. The weird thing is, /usr/bin/python already points at /usr/bin/python2, but autobuild still picks up python 3... > If it does not work, you may trick the build system by creating a "python" > link to the python2 binary and then changing the PATH so that your link is > found first. E.g. from a terminal: gonna try that. Why didn't I think of that myself (no I do not want the obvious answer :P) cheers LC From Lance.Corrimal at eregion.de Sun Sep 23 01:56:52 2018 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 23 Sep 2018 10:56:52 +0200 Subject: [opensource-dev] specifying wich python binary to use? In-Reply-To: <10078256.3HTcpH6jeW@kumiko> References: <6278903.yOKPxsPXRU@kumiko> <20180922160031.ca89a2b8c29b332dfb5d8a7c@free.fr> <10078256.3HTcpH6jeW@kumiko> Message-ID: <3197479.NkBEeXKG2W@kumiko> Am Samstag, 22. September 2018, 16:53:27 CEST schrieb Lance Corrimal: > Am Samstag, 22. September 2018, 16:00:31 CEST schrieb Henri Beauchamp: > > On Sat, 22 Sep 2018 15:43:14 +0200, Lance Corrimal wrote: > > > I have python 2 and python 3 installed on my system, is there a way to > > > specify which python version autobuild should use? by default it tries > > > python3, which fails. > > > > Depending on your distribution, you may specify (or not) which Python > > version is to be used when invoking 'python', with: alternatives --config > > python > > looked into that already, didn't work. > The weird thing is, /usr/bin/python already points at /usr/bin/python2, but > autobuild still picks up python 3... > > > If it does not work, you may trick the build system by creating a "python" > > link to the python2 binary and then changing the PATH so that your link is > > > found first. E.g. from a terminal: > gonna try that. Why didn't I think of that myself (no I do not want the > obvious answer :P) the trick with the link did not work either, cmake is evil enough to actually search for python binaries WITH the attached version number. BUT there is a variable that you can pass to autobuild, to pass it on to cmake, that contains a list of the version numbers to search for... -DPython_ADDITIONAL_VERSIONS:STRING="2.7 2.6 2.5 2.4 2.3 2.2 2.1 2.0" with this autobuild does not find python3 binaries, and all is well. Cheers LC From cinder at alchemyviewer.org Sun Sep 23 04:22:03 2018 From: cinder at alchemyviewer.org (Cinder Roxley) Date: Sun, 23 Sep 2018 07:22:03 -0400 Subject: [opensource-dev] specifying wich python binary to use? In-Reply-To: <3197479.NkBEeXKG2W@kumiko> References: <6278903.yOKPxsPXRU@kumiko> <20180922160031.ca89a2b8c29b332dfb5d8a7c@free.fr> <10078256.3HTcpH6jeW@kumiko> <3197479.NkBEeXKG2W@kumiko> <3197479.NkBEeXKG2W@kumiko> Message-ID: I usually setup a virtualenv for each viewer since several tpvs use different forks of linden?s autobuild. virtualenv ./autobuild source autobuild/bin/activate pip install llbase pip install 'https://bitbucket.org/lindenlab/autobuild-1.0' On September 23, 2018 at 3:57:07 AM, Lance Corrimal ( lance.corrimal at eregion.de) wrote: Am Samstag, 22. September 2018, 16:53:27 CEST schrieb Lance Corrimal: > Am Samstag, 22. September 2018, 16:00:31 CEST schrieb Henri Beauchamp: > > On Sat, 22 Sep 2018 15:43:14 +0200, Lance Corrimal wrote: > > > I have python 2 and python 3 installed on my system, is there a way to > > > specify which python version autobuild should use? by default it tries > > > python3, which fails. > > > > Depending on your distribution, you may specify (or not) which Python > > version is to be used when invoking 'python', with: alternatives --config > > python > > looked into that already, didn't work. > The weird thing is, /usr/bin/python already points at /usr/bin/python2, but > autobuild still picks up python 3... > > > If it does not work, you may trick the build system by creating a "python" > > link to the python2 binary and then changing the PATH so that your link is > > > found first. E.g. from a terminal: > gonna try that. Why didn't I think of that myself (no I do not want the > obvious answer :P) the trick with the link did not work either, cmake is evil enough to actually search for python binaries WITH the attached version number. BUT there is a variable that you can pass to autobuild, to pass it on to cmake, that contains a list of the version numbers to search for... -DPython_ADDITIONAL_VERSIONS:STRING="2.7 2.6 2.5 2.4 2.3 2.2 2.1 2.0" with this autobuild does not find python3 binaries, and all is well. Cheers LC _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20180923/cd4bb7dd/attachment.htm From sldev at free.fr Sun Sep 23 05:19:20 2018 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 23 Sep 2018 14:19:20 +0200 Subject: [opensource-dev] specifying wich python binary to use? In-Reply-To: <3197479.NkBEeXKG2W@kumiko> References: <6278903.yOKPxsPXRU@kumiko> <20180922160031.ca89a2b8c29b332dfb5d8a7c@free.fr> <10078256.3HTcpH6jeW@kumiko> <3197479.NkBEeXKG2W@kumiko> Message-ID: <20180923141920.782ee9206ac6664d23a92387@free.fr> On Sun, 23 Sep 2018 10:56:52 +0200, Lance Corrimal wrote: > the trick with the link did not work either, cmake is evil enough to > actually search for python binaries WITH the attached version number. cmake is for nothing in this behaviour (else, I'd encounter it as well for my viewer and distro, the latter also having both python2 and python3 installed). It's likely a bug in LL's build system... Note that my viewer is using a largely modified build system (derived from Snowglobe v1's), that can build on pretty much any Linux distro (but for 6+ years old ones, since they won't fulfil minimum cmake and/or gcc versions requirements), and which does not rely on any external resource (such as "autobuild", "llbase" and all that non-sense)... Glad you found the solution however. Henri. From rhona29432 at aol.com Fri Sep 28 17:14:53 2018 From: rhona29432 at aol.com (Sarah) Date: Fri, 28 Sep 2018 20:14:53 -0400 Subject: [opensource-dev] [viewer-development-commits] commit/viewer-release: 76 new changesets Message-ID: <16622ad9084-1ec5-2af3@webjas-vae147.srv.aolmail.net> S -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20180928/7708c881/attachment.htm