Bugs / Known Issues

Yes i think this is normal behaviour, as you can interact with chatbubbles or user title displays etc, by right clicking on a persons bubble it will bring up their agent pie menu.

I've had this problem, seemingly randomly, in the Windows client over the past several releases.

Client attempting to download a new version of itself to the Applications folder results in a spontaneous explosion of the client (I'm guessing you guys already knew this).

It's actually trying to download the Mac OS X update.

Heh, it's no wonder:

When you try to download a new version you get the following error:
2006-02-16T14:48:24Z WARNING: ll_apr_file_remove failed on file: /usr/home/jandrese/secondlife/SecondLife/logs/SecondLife.exec_marker
sh: /usr/home/jandrese/secondlife/AutoUpdater.app/Contents/MacOS/AutoUpdater: No such file or directory

Apparently SL thinks I'm on a Mac.

- when switching to another desktop and coming back to SL, the "build" button often turns itself on spontaneously
- taking snapshots to disk doesn't seem to save any files
- trying to email a snapshot crashes SL
- occasional SL crashes when changing screen resolution (not X display resolution) while SL is running

I've been taking screenshots with xwd instead of the built-in system. It means getting the UI in the shot, but it's a decent workaround for now.

I can't select to enable Shiny Objects through the preferences window, but I found out that deleting or changing the value of RenderObjectBump to TRUE will do just that. From what I can tell though, things are still not actually shiny that should be. Changing the Shine between any of the settings doesn't change the appearance.

Also, is it known that the reason floating text gets doubled is because of \n? I haven't seen it mentioned anywhere yet, not that I've looked through the entirety of this forum yet. ^.^ Anyways, any line of text before the linefeed gets repeated, while anything after or without \n present appears normally. I presume it's the same reason why the group titles get doubled assuming the SL using the same LF in the text for group and avatar names.

EDIT:

Also, when exiting the Appearance window, I am always prompted to save all changes 'irregardless' of it there is actually any changes that need to be saved.

Hope these haven't been said hundreds of times already!

I have this too, but only with some outfits. With most of my clothes, this does not happen.

It's always good, I think, to get confirmation of problems. Otherwise the impression can arise, that only one person has the problem

I can assure you, relying on curl or OpenSSL is not a good idea. I learned this one the hard way distributing my own software.



Incorrect. Getting the right TrueType font metrics *requires* the patented interpreter. You may or may not believe visual quality is inferior, but the autohinter changes glyph size and this can break pixel-based window layouts (which I think is what SL uses for the GUI).



Yes, that's possible (that they could be missing it entirely). And googling for different libvorbis sonames shows at least three or four, so I'm not at all sure about that claim of stability.



All distros "suck beyhond belief" when it comes to distributing binary software. You may not think this is true, but come back when you've distributed 10,000+ binary packages to Linux users and resolved their complaints. I think you'll have a different opinion.



It's an absolutely massive deal. What you need to understand is that open source software has different levels of acceptability for "just works"-ness. It's OK for GWidget to take an hour for an expert to resolve dependencies because the author probably doesn't care much how many users he has. It's absolutely not OK for the same to be true of Second Life, because:

a) If it doesn't work, Linden Lab gets tech support requests they need to deal with. This includes problems of the form "libFoo is available in the repositories but is not installed".

b) If it doesn't work, Linden Lab get a bad reputation

c) If it doesn't work, SL doesn't grow and LL does not make more money.

Given a choice between conservatism over what libraries to ship and the risk of people saying "I tried SL but couldn't get it to run, it must be crap" it's obvious which is going to win.

Linux is not a platform, period. Any library except for glibc and Xlibs (which have strict backwards compatibility policies) can disappear at any time, thanks to distributors habit of dropping libraries that are no longer used within the distro itself. As you cannot predict what libraries the user may have installed, the only option is to ship them all. If you don't like this reality then join the club, but denying it exists won't help.

As a linux fan, I hate to say this, but I agree totally.

I have used linux for years, and I would rather have an app with its own libraries, which work, or statically linked, than HAVE to rely on compatibilty.

And as Linden Labs, I would be crazy to open the can of worms of having to support a maybe home-grown linux setup that "won't run cos LL has a bum apllication".

I have already heard that under windows! And MACs. Without the "creativity" that can make up the bundle the user calls linux.

And linux comes in more flavors tha ice cream...

I'm not sure if anyone's mentioned this before, but I haven't been able to find it mentioned. I'm running the SL client under OpenSuse, and it mostly runs great. But when I try to use the upload feature, nothing happens. Is this a known issue? If so, is there some sort of fix for it?

I think you may have cut out the most important line:
INFO: remove_marker_file()

It seems something goes wrong when SL trys to read from the settings.ini file in the SecondLife/user_settings/ directory. Deleting it before running the client fixes the problem - unfortunately that means were stuck with default settings :-/

The Couldn't initialize* lines occur during the successful first run of the client (look at the log output as it starts) as well, it just seems to ignore those though.

My setup:
Gentoo 2005.1
Enlightenment DR17 (0.17)
Linux 2.6.12-gentoo-r6
X.Org version: 6.8.2
Video Driver: radeon (kernel provided module)
ATI Technologies Inc Radeon RV200 QW [Radeon 7500] (64MB)
GenuineIntel Pentium III (Coppermine) 731.222MHz, 256KB cache
Phys Mem: 515336k, Swap: 1004052k
==Chris

a) It is known, and a big pain. Sending snapshots by email, downloading to disk, uploading from disk, all not working yet.

b) No known workaround, and the fix is coming... sometime, we all hope, but probably not much before SL 1.9 has settled down.

I still enjoy the alpha - for an alpha, I find it very good!

As a Linux fan, I'd have to disagree. Quite a few libraries these days are keen on keeping strict binary compatibility (zlib, libogg, and libvorbis are among these; you realize how many people would have problems if they updated one of these and it turned out to be incompatible with all existing programs that rely on it? Yet, in the 2 years I've been using Linux exclusively, this has never happened). If binary compatiblity breaks, they change the soname the program links to, so you can still install the required version next to the latest binary-incompatible version.

I understand, and agree here too. I CAN get a dynamically linked opera now, but it is Version Dependent (Suse). When I upgraded recently, dynamically linked versions of Opera for Suse had 5 options; there were also separate versions for 18 flavors of Linux.

What still is a problem, is the phrase "quite a few libraries" above.

If LL wants to keep it robust, then they will isolate those libraries that make NO difference to SL, and bundle the rest with the client.

The other option is what Opera does: http://www.opera.com/download/index.dml?opsys=Linux%20i386&lng=en&ver=8.52&platform=Linux%20i386&local=y.

I am not sure taht is a practical solution, really...

Well it is the first release of the Alpha, you can't expect everything to be working.

More importantly, there is a workaround for taking snapshots to disk. Just use xwd or another similar external screencapture program to take the screenshot. You'll get the UI by default, but it does the job. Sadly, there is no workaround for texture uploading yet, but hopefully that stuff will appear in the next version.

Also, the "download new version automatically" feature doesn't work yet, because it tries to use the MacOS updater.

Ok, got some feedback from Arjanv about the workarounds I was having to employ to get the client to run with SELinux enabled. He seems to feel that rather than requiring special install-time action, the libraries aren't being built right. To wit:

On needing to execstack -c libraries (which marks the stack segment as being non-executable), the libraries are either lacking stack markings entirely or are explicitly marked execute.

[SecondLife-linux-02072006]$ for f in lib/* ; do echo $f; readelf -l $f | grep STACK ; done
libapr-1.so.0
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
libCgGL.so
libCg.so
libcrypto.so.0.9.7
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
libcurl.so.3
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
libexpat.so.0
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
libfreetype.so.6
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
libgcc_s.so.1
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
libGLU.so.1
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
libjpeg.so
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
libkdu_v42R.so
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
libogg.so.0
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
libSDL-1.2.so.0
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
libssl.so.0.9.7
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
libstdc++.so.5
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
libvorbisenc.so.0
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
libvorbisfile.so.0
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
libvorbis.so.0
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
libxmlrpc.so.0
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
libz.so
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
libz.so.1
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4

libCg* don't have any stack markings at all, and I'm not sure if we can do anything about that at build; doesn't Cg stuff come straight from (nvidia? ati?) as binaries? Well, I guess LL could execstack -c them before distributing them, but in that case they should really push upstream to get them built better.

Of the others, note that libcrypto and libkdu_v42R both explicitly are marked for an executable stack. Clearly they work fine when I fix them, so the marking isn't right. Arjan says:



Now, as for SELinux cowing about text relocations and requiring a chcon -t textrel_shlib_t, he says that's not the right way to fix it either; again it needs to be built differently:



Feel free to disagree, but I personally don't argue with kernel developers about code

~Orenj~

3-D acceleration doesn't seem to work at all on my dual-monitor system. I used to use the Windows client in Wine .9, which gave me around 25~35 FPS most of the time, with the graphics settings set kinda high. However, when I added the second monitor to my video card, it stopped working in Wine (gasp?). So, I decided to try the Linux client. I get around 3~7 FPS with the settings turned way down. The setup I have is Xinerama across 2 monitors, both plugged into one video card. Other games seem to run with acceleration, though, and glxgears reports around 7000 FPS on either monitor.

---EDIT---
I did try playing with the settings.ini, including changing the video RAM to 128. It says it sets it to 128 in the messages when it loads, but doesn't run any faster.
---EDIT---

Mandatory specifics:
- Fedora Core 4 64-bit
- KDE 3.5.1, with Xinerama dual-head
- Linux ilikemonkeys.no-ip.org 2.6.15-1.1831_FC4 #1 SMP Tue Feb 7 13:37:59 EST 2006 x86_64 x86_64 x86_64 GNU/Linux
- X.Org version: 6.8.2
- NVidia driver: 2.0.1 NVIDIA 81.74
- NVidia GeForce 6600 GT/PCI/SSE2, 128 MB
- AuthenticAMD, AMD Athlon(tm) 64 Processor 3500+, 2210.219 MHz, 512 KB cache
- Mem: 1020624k total, Swap: 6000268k total

What does "About Second Life" from the help menu have to say about your video hardware and acceleration?

OpenGL Vendor: NVIDIA Corporation
OpenGL Renderer: GeForce 6600 GT/PCI/SSE2/forceSW
OpenGL Version: 1.2 (2.0.1 NVIDIA 81.73)

Now that I look at that closely, could "forceSW" mean "force software rendering"?

---EDIT---
Logged out, played with settings.ini some more, and now it doesn't say forceSW in the about dialog! It's still only giving me around 7~11 FPS, though, when I know it should be able to do MUCH more.
---EDIT---

---EDIT2---
Installed the new Nvidia drivers (817, with the patches from the forum, and everything's working fine. So, everyone, please excuse my stupidity. >.<
---EDIT2---

There's a far easier way of doing this:

~ $ startx -e /home/user/secondlife/secondlife

I have a bug of my own, which has been mentioned elsewhere, and may also be present with the Windows Client (though I cannot check).

The SOCKS proxy settings don't seem to make any difference.

The SOCKS proxy I'm using is a SSH-created one which kindly redirects traffic through my uni's HTTP proxy. (using ssh remotehost -D port)

It would be nice to see support for HTTP Authentication proxies sometime too.

Remember the words of the great camel... "TMTOWTDI"

Could you share the settings.ini tweaks?


- d.

I would, but I'm not quite sure what I did, or if it was even something that I did that fixed it. Installing the newest Nvidia drivers definitely helped, though, although in some places I still get around 1~2 FPS when I used to get higher. I suspect this might be due to the "1 MB RAM" thing, as these areas are chock full o' textures.