Bugs / Known Issues

Runs great, only two issues I can see. Some textures don't display properly and when I go back to windowed mode from full screen SL crashes. Actually it seems to think my graphics card has only 16 MB of Ram when it has 128 DDR.

As an after thought I added my sys info:

AMD XP 2200+ (1.8Ghz)
768 DDR (266 bus speed)
50 GB HD space over two drives a 20 and a 30
Running a new and up to date install of SuSe 10 OSS, not the pro version.
Using a XFX GeForce FX 5200 with 128 DDR and SuSe's NVIDIA drivers installed.

Avatars do not draw in the game for me. Every avatar request is apparently returned null according to the command line:

2006-02-11T07:19:37Z WARNING: Frame buffer has less than 8 bits of alpha. Avatar texture compositing will fail.
2006-02-11T07:20:33Z WARNING: process_avatar_init_complete() with NULL avatarp.
2006-02-11T07:20:33Z INFO: process_avatar_info_request()
2006-02-11T07:21:39Z INFO: Setting LLAgent::mAvatarObject to NULL

This sounds like a configuration error, but I have no idea how to increase the number of bits dedicated to the alpha channel. My first thought, bumping the card up to 32 from 24 bit mode was a complete flop as X refused to start in 32 bit mode (not supported).

OS: FreeBSD 6.0 using the Linuxulator with SUSE 9.3 libs
Desktop: Windowmaker
Kernel: FreeBSD escaflowne.ceyah.org 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Wed Jan 25 20:09:02 EST 2006 [email]root@escaflowne.ceyah.org[/email]:/data/src/sys/i386/compile/ESCAFLOWNE i386

X version: vendor string: The X.Org Foundation
vendor release number: 60900000
X.Org version: 6.9.0

GL: OpenGL renderer string: GeForce FX 5900/AGP/SSE/3DNOW!
OpenGL version string: 2.0.1 NVIDIA 81.78

Video card: GeForce FX 5900 w/128MB
(note, I did the settings.ini trick where I bumped the memory to 128, according to the command line, it's using 128MB)

Memory: 768MB, 2GB swap available (never got used)

I get a segmentation fault within a few seconds of running the binary. I get the following backtrace from the core file:

#0 0x00a14141 in strncpy () from /lib/libc.so.6
#1 0x08344091 in LLVertexProgramGL::load ()
#2 0x09b3a31b in LLVOAvatar::initVertexPrograms ()
#3 0x09ae56da in LLViewerWindow::initGLDefaults ()
#4 0x09ae41bc in LLViewerWindow::LLViewerWindow ()
#5 0x09dd4d57 in main ()

My system is running Fedora Core 5 test on an AMD Athlon XP with a Radeon 9200 using the DRI r200 driver. The driver has no support for vertex programs. I can provide more information on request.

The potential problem I see is that most of these libraries have been the way they are now for a long while, and aren't likely to really screw up. libstdc++ on the other hand (which isn't being bundled), that's kind of a bad space at the moment with people upgrading from gcc-3.3.x to newer versions (which have v6 instead of v5), and an actual threat to the client.



Believe me I know, and as far as performance tuning options are concerned, this isn't the primary thing I was concerned with. Those libraries have had a (reasonably) stable API for awhile, but talk to a large number of other things. Eliminating them IMHO might be a way to cut down the "surface area" of the client (speaking very, very figuratively) and could potentially reduce the number of things one has to worry about. That's why I mentioned it.

Either way, sorting out what does and doesn't need to be shipped for the majority of targets is just going to be a big mess I don't envy Icculus in the least. (I have my own problems just hammering on X7.0 right now)

Using the .9 client from a few days ago, I just this morning noticed that I'm seeing group names appear twice in the naming balloons...

Like:

Second Life Mentor
Second Life MentorJesse
Mackenzie

...and so forth.

Oh, and still no sound.

(Same system specs as before, just the newer client)

Whew! You said a mouthful

It was on Icculus' behalf that I put forward the idea that the shipped package as is should be tested. Of course, Linutics being what they are, a lot of people are going to have "invented a better wheel". I just hope for a bundle that does not depend on too much of my own system, in a vain and futile attempt to keep application and system separate issues.

It may be necessary to kep a support forum running for Linux. I don't see that this is something we can totally offload onto LL

The In World Linux Group is a good start, though.

Its my observation that these problems seem to vary gretly from Linux distro to distro. I've seen far less problems than most people have described on SuSe Linux 10. I suspect its because of quality control in respects to each distro. Fedora Core having used FC3 myself for a long time doesn't display nearly the quality control and assurance that SuSe does. I'm comparing the the problems I've seen reported here to my install and I'm just bring this up. If I may suggest to the Lindens that may read this to pick a sane distro. I recommend SuSe over others since I've taken the time and effort to evaluate and use quite a few distros. These are my thoughts taken em or leave em. In closing I want to add one bug to this I've seen since the last report. textures seem to take a long time to load at times when they don't do that in the win32 version.

With the numerous number of bugs I'm seeing scattered all around the forums (Many of them duplicates) I think that now is a good time to add a bug tracker on the site (like bugzilla or something).

This would keep users informed of the developers' progress with certain bugs, and could [hopefully] prevent duplicate reports.

Anyone else think this would be beneficial?

Seconded.

Thirded

Though the things that don't work, are roughly the things listed by Don initially.

What we also have is hardware related issues; and a lot of this will have to be done by the tried and tested "post it and hope" method, I think...

A lot of people on this forum, me included, are not regular posters, I think. An additional structuring, via Bugzilla, could help with this.

What we REALLY need is a minimum dependency list. How many problems will we be able to solve by simply saying "RTFM, n00b" :3

Mentioned elsewhere, too.

I send a snapshot by email, and get:

2006-02-12T18:06:11Z INFO: Starting transfer for 87c38c33-0292-34f7-06da-d6eb0d32b484
2006-02-12T18:06:12Z INFO: Receiving 0c4ea387-a13d-51d1-76bc-58ccd9855605, size 677 bytes
2006-02-12T18:06:12Z INFO: Toggling render debug feature mask 1 off
2006-02-12T18:06:12Z INFO: Toggling render debug feature mask 1 on
2006-02-12T18:06:43Z WARNING: JPEG parameter struct mismatch: library thinks size is 428, caller expects 372
2006-02-12T18:06:43Z WARNING: LLImageJPEG decode failed: JPEG parameter struct mismatch: library thinks size is 428, caller expects 372
2006-02-12T18:06:43Z INFO: remove_marker_file()

I don't think all is relevant, but the last few lines are, perhaps.

Found the problem. Apparently the Avatar Vertex Program is broken, disabling it causes avatars to draw normally.

I don't know what to say about this other than you're very wrong.



may have certain protocols compiled out doesn't mean anyone will be stupid enough to ship a cURL with http lopped out of it. (Okay, not counting Gentoo ricers)



The patented interpreter has been inferior to the one Freetype added to avoid it for almost a year or more now.



They'd basically have to be missing ogg entirely, since it's also not had a major API change in well over a year, if at all. It certainly seems to have kept the same sonames for a long, long time.



For one, that would give an easy "out" for passing control over which sound engine to use to the distro, eliminating a configuration item. For the other, SDL is very, very common. Any distro that doesn't outright suck beyond belief is going to have a package for it available.



Are you sure you're not stuck back in 1995 or something. This is not a "flaw" in Linux, nor is it even really an issue. All of the open source libraries this client ships with is available and presently shipped with virtually every distro out there. If someone's going to try to install it on a libc5 system or something like that, it should be kept between them and their psychiatrist. If they want to install it without the proper support libraries, it should be no different from if they were to have attmpted to install it on a box without X. It's not a huge deal to require they install the appropriate dependent libraries supplied by their distro.

Believe me, I'm very familiiar with sorting out which libraries don't work with what. I'm one of the guys who maintains the Dropline Gnome packages. I've been building most of my own binary packages for many years now. There's just not been a lot of API changes with most of these libraries that a reasonably up to date distribution can't handle. The worst problem that I see, and literally the only problem, is that we've already got some people who are mainly using gcc 3.4.x/4.x now, which ships a different version of libstdc++, but again, most distros ship at least one package with "legacy" versions of that shared lib.

For *now* it makes sense for them to stay to avoid creating more bugs due to library obscura, but for the long term they're probably not going to be needed much longer.

The way the client package is now, that amounts to glibc 2.3.x alone, although it's very possible that someone could get away with using something as old as glibc-2.1.x.

The client absolutely requires glibc 2.3.x (I'm not sure it technically requires 2.3, but it's been linked against 2.3 so suddenly it's all wah wah I need the glibc2.3 symbol versions wah).

You can still run it on a glibc 2.1 distro if you grab a precompiled glibc 2.3 and do the appropriate stuff to make sure SL uses it (this is what I successfully do - I can go into more detail if anyone cares).

That's the GL Utility library, which isn't standard nor part of OpenGL. I don't believe it is standard with Xorg or even with NVidia's drivers. So it will need to be included.

The acceleration comes from the video driver, which for NVidia may be either the Xorg/mesa driver shipped with Xorg or NVidia's binary driver if the user installed that. That's what provides 3D acceleration (by implementing OpenGL), either via Xorg's standard DRI (Direct Rendering Interface), or in the case of NVidia, via their custom loadable kernel module.

Any respectable OpenGL implementation will come with a GLU library (which I think is required for a proper implementation; GLUT is a different matter, though). You'd be very hard pressed to find an OpenGL program that doesn't use it. That aside, since LL is seemingly linking against a binary-incompatible version of GLU than what most people have, it will need to be included.

Uploads not working, never even see dialog box for em.
# Linux Distribution-PCLinuxOS .92, it's related to mandrake
# Desktop Environment-KDE
# Kernel info -Linux localhost 2.6.12-oci6.mdk-i586-up-1GB #1 Thu Oct 27 15:39:01 CDT 2005 i686 AMD Athlon(tm) 64 Processor 3500+ unknown GNU/Linux
# X version-X.Org version: 6.8.99.901
# Video driver-nvidia 8174
# Video card model & amount of video memory-GeForce 6100 integrated into mobo, 64MB reserved
# CPU info-Vendor: ‎AuthenticAMD Model name: ‎AMD Athlon(tm) 64 Processor 3500+ Frequency (MHz): ‎2209.854 Cache size: ‎512 KB
# Amount of physical and virtual memory-Mem: 1165596k total Swap: 3887676k total

Could you reduce the minimum color requirement from 32-bit to 16-bit? My Radeon 9000 has way faster OpenGL accel under X.org 6.9 in 16 bpp mode than 32 bpp.

See? A bug management system would help to sort out duplicate bug reports and feature requests. I really think this should be addressed, or we're gonna see a million and a half reports of the same bugs over and over again.

Oh, and Ari Pickles, the best place to request features would be the Feature voting page, not the linux alpha bug thread.

http://secondlife.com/vote/

SecondLife requires an alpha channel to properly work. 16-bit color doesn't have an alpha channel (even though 5.5.5.1 or 4.4.4.4 could fit into 16-bit, I don't think these are well supported pixel formats, and SL wants at least 8 bits anyway).

Actually it's a rather standard part of Xorg.



If this were entirely the case, we *should* see it showing up somewhere with ldd, but it's not.
I'd double-check, but it seems I left my desktop machine sitting in XP when I left for work. Just run ldd on everything in bin/ and lib/ in the client archive and you'll see what it's calling for.

1. I've noticed that name/title bubbles block the on-touch event in the viewer.
2. Gamma doesn't work
3. llLoadURL doesn't appear to work either

This is the case under WINE too, so I assume it's expected behaviour.