1.10.1 Released!

I already offered to do it freelance, and I was more than half-serious. It's defitinely a possibility I think LL should consider.

Don't lose momentum here people, if we keep informing the Lindens, they will sit up and listen.

Well done everyone sending in debug and log files and posting the findings here.

Torley is on the case.

Do any of these Lindens know their asses from the elbows? Why should we believe them?

I will dedicate myself and my team (I have a Dedicated Linux Squad) 2 days a week to this.

If the Lindens are too busy we all can push together to produce a result.

Greetings,

Thanks for your inquiry.

Second Life does not currently have a Linux version. Some Second Life
residents have reported success running Second Life under Windows-
emulation software such as Wine.

Regards,

Martin Linden

How's my driving? Rate Second Life Support:
https://secondlife.com/account/csr-survey.php



UNQUOTE

This was sent to me yesterday.
C'mon they must be under some serious pressure at the moment (Re: above - huh??)

Three updates in a week = insufficient testing.
Insufficient testing = incompetence in my book.

The benefit of forums in most situations is to help the users help themselves.

However, in this case all the users can do is tweak settings.ini and various other pointless exercises. This flaw has been going on for some time.

Now, because you are CLOSED SOURCE the only people that can help us with this particular issue are the Lindens.

NOTE TO (TORLEY) the Lindens: We are doing all we can and we will continue to do so, but our hands are tied. Ultimatley, all we can do is feed information back to you - please act on it.

I'm about to have to speak with my $9.95 a month. 2 more days without a client, and I think I am gone, taking my money with me. Yeah, I know the client is alpha and can't be relied on, but I came to SL in the first place because they had a native linux client. I can look past sound, and being a half version behind windows clients, but having nothing stinks. 2 more days. I wouldn't be bitching if I had a free account, but I'm paying for something I can't use at this point.

Perhaps they are short on software developers?

http://lindenlab.com/employment/software_dev

Look at the openings they have. They perhaps need more people to support the software base and user base that they have. Though I have to say their job descriptions are rather plain and short, I can see why they have been there for months.

It may be more helpful to further SL by helping with descriptive bug reports, figuring out what is wrong with the client and documenting it instead of pestering them to release the source. The client can be run with a debugger running along side it so fatal bugs can be caught and the output of the debugger will tell the programmer where the error happened.

Ahh, wasn't aware. See, I am all over that idea.

And does the SL client do any form of thread scheduling, even emulated threads with something like setjmp/longjmp or a duff device. Between the network settings seeming to reduce the issue, and the error only really seeming to occure on the Linux client .. so it would pressumably be in linux specific code, which isn't likely the octree at all unless someone is a pretty shobby coder. Kinda leads me to believe that the network side that is propigating the octree, and the rendering side that is using it, are racing eachother and making various objects invalid. Someone forget a mutex somewhere?

Just want to chime in that the native linux client alpha crashes for me as well, with the same symptoms as described. The 1.9.0-21 client did not exhibit this behavior, but all 1.10* versions have.

I can log in and do just about anything for anywhere between 10 seconds to 2 minutes (perhaps depending on the complexity of my location?) before it crashes suddenly. The only new messages that appear in the console at the time of the crash look like these two:



Those two lines show up every time I crash this way, but not when I exit normally (at least, they are not the last messages when I exit normally). The messages before those vary depending one what I am doing in-world at the time of the crash.

I tried adding the two settings.ini lines mentioned in this thread, "UseOcclusion FALSE" and "DebugPermissions TRUE" (with a tab inbetween, not a space). After adding those lines, at the end of the log-in process (but before I could see anything in-world) the console was flooded with dozens of Octree Warnings, then crashes immediately.

From testing using just one or the other of the settings, it looks like UseOcclusion has no effect at all (which is to be expected, since it seems to be unavailable for the Linux client), but DebugPermissions causes the flood of warnings and the insta-crash.

Interesting little tidbit: Looking at the settings.ini after the crash, and the two lines I added had vanished (not just moved or sorted alphabetically, but actually gone). Even though the lines were gone, the client continued to produce the insta-crashing behavior until I added the lines again, this time setting DebugPermissions FALSE. The next log-in (and each login after that) was back to the usual "mystery crash after 1 minute or so" behavior -- and the config lines were once again missing! Sherlock Holmes would love this one, I think.

Running the Windows client through WINE works quite well for me (sound, including streaming audio, is present but choppy if I turn on emulation in winecfg, but I'd rather have silence, so I turned it off).

There is one peculiarity running in WINE, though: If I edit my appearance, I become the wolf man! No, really, it's just a problem with alpha channels in hardware texture compositing, so that my face is covered with my hair color/texture. (It's not just the head -- similar things happen with other parts, e.g. if I edit my shirt, the sleeves will extend out to my fingers, no matter the sleeve length).

Luckily, the wolf-man effect isn't permanent unless I change/save my appearance -- if I cancel, it just reverts to the baked texture from before my amazing transformation. My date to the formal was quite surprised the first time it happened, though!

I can also force this behavior through Debug menu -> Character -> Rebake Texture. I'm pretty sure it's just some oddity with WINE. This doesn't occur in either the Linux or Mac clients (with the Mac version running on a different machine). I checked, just to be sure, and this occurs during any phase of the moon, not just during a full moon.

I suspect your lines are formatted incorrectly. The SL viewer appears to destroy lines that it does not recognize as it simply ignores it and then recreates the file after.

Remember, it is always a TAB between the name and the value, not a space, or 8 spaces. But a hard tab.

UseDebugMenus TRUE
UseOcclusion FALSE
DebugPermissions TRUE

Add them and make certain that you have a single tab between the variable name and its setting.

The Linux client is in Alpha testing. There may (and most likely will) be bugs in the code that will need fixing. If you are relying on Second Life for mission-critical things (running a business, for example) we suggest you use either the Mac build or the Windows build, depending on what sort of hardware you have available.

We are compiling these bugs and getting people on them as soon as possible. Please hang in there! Until then I'll work on trying to find a workaround. No promises! (I'm a Mac user!)

The bug seems to be located in 0x09634921 in LLSpatialGroup::updateInGroup() as told by a debugger. It's a segmentation fault that occurs at login. It's reported in the first thread in the group. With a debug version a percise bug report can be generated. Though that address should give you some info on what is happening.

Makes me want for the source now.

Seeing the source is a lot of responsiblity and such! I'd only want to do that if I were paid. However a debug version would give tons of information when and where the error happened. It would also be pretty safe to give out though a debug version is easier to reverse engineer which they may not want to risk.

Thanks for the update

Yah, I know the feeling on the source side. Though at the same time, it isn't necessarily that big of a deal. It is always possible to do most of the development remotely and just retrieve your own binaries for testing locally so you can shave off some of the worry about breach of local security. A bit of an inconvenience at times, but it is easily feasible, and easily written into any sort of contract for hire and or NDA.

So far as the debug version, yah, it would give quite a bit more useful data, but it tends to make people a bit uncomfortable. Would be nice though.

Thanks for comming, Brent! Some of the items look like to be the same as MacOS X problems, since MacOS X and Linux are basically Unix underneth. What affects one may very well affect the other. Anything we can find and post here you're welcome to look at.

Currently, there's no work-around with just the native Linux client. We have to get our computers drunk with Wine just to get into SL with the Windows client (and that's not perfect, nor as fast).

Any help is appreciated. We were about to form a search party to find where Don Linden is...

That isn't exacly a true statement. I can't use Wine, and I have been in SL for most of the day since the new linux client was released. Except for when I was tinkering with finding specific behavior to cause a crash, or when auto logged out due to being away. Admittedly I can't travel around very quickly, and I have to avoid sim edges, but I can indeed get in and stay in.

Granted, there are a few who are in and can work to assist. But a majority of Linux users can't.

Brent, we're more of a sysadmin mentality. No need to explain things like we're in Teen SL. Some of us built the hardware we run SL on. We know we're testing a client out. We're giving Linden Labs feedback about it. All we need is some attention, a progressive improvement from alpha to beta, and we'll be happy to help out.

Program received signal SIGSEGV, Segmentation fault.
Invalid type combination in ordering comparison.
0x09635ed4 in LLSpatialGroup::removeObject ()

Here is a gdb backtrace of the actual crash:

#0 0x09635ed4 in LLSpatialGroup::removeObject ()
#1 0x0963dc05 in LLSpatialPartition::remove ()
#2 0x09f101dd in LLPipeline::unlinkDrawable ()
#3 0x087c6305 in LLDrawable::cleanupReferences ()
#4 0x087c5e9e in LLDrawable::markDead ()
#5 0x09ae7f73 in LLViewerObject::markDead ()
#6 0x09b1fe1a in LLViewerObjectList::killObject ()
#7 0x09b1fe69 in LLViewerObjectList::killObjects ()
#8 0x09b9f25a in LLViewerRegion::~LLViewerRegion ()
#9 0x09e809f7 in LLWorld::removeRegion ()
#10 0x09e89306 in process_disable_simulator ()
#11 0x082fa8cc in LLMessageSystem::decodeData ()
#12 0x082e4e28 in LLMessageSystem::checkMessages ()
#13 0x09f5603d in idle_network ()
#14 0x09f57329 in idle ()
#15 0x09f49705 in main_loop ()
#16 0x09f42b95 in main ()

Yah, crash so far has always been in first thread. Though not always the same cause. This one was another SIGSEGV, but in a totally different location. Was flying towards a SIM boundry in Elpenor when I triggered this.

Invalid type combination in ordering comparison.
0x087d0431 in LLPointer<LLDrawable>::unref ()

backtrace as follows:

#0 0x087d0431 in LLPointer<LLDrawable>::unref ()
#1 0x096349f8 in LLSpatialGroup::updateInGroup ()
#2 0x0963dc8b in LLSpatialPartition::move ()
#3 0x087c9613 in LLDrawable::moveUpdatePipeline ()
#4 0x087c9d6c in LLDrawable::updateMoveUndamped ()
#5 0x087c975e in LLDrawable::updateMove ()
#6 0x09f1261a in LLPipeline::updateMove ()
#7 0x09f5802a in idle ()
#8 0x09f49705 in main_loop ()
#9 0x09f42b95 in main ()