Crashes with 1.10.0.32 - any tips?

I just wish a Linden could tell us anything either way - alpha shouldn't mean unsupported.

I'm actually really stable, and my framerate is incredible compared to what it was before.

The problem I've got is that the moment everything renders, on startup or while teleporting, my client dies. I've had a couple of instances where it crashes while I'm already in place, but they're pretty rare, while the tp/login problem is common.

lol!

The suggestion was good

Only later I found out the option is not available from the GUI.

So the changed behaviour was not due to the suggestion, which was fine, and sensible anyway, considering the octree errors we have

This does not seem to work for everyone; in my case, the option was simply removed from settings.ini when I started SL, and was on anyway

It doesn't seem to work for me. If it's any help, here's the crash location from dmesg:

secondlife-bin[19341]: segfault at 000000000edcaa7c rip 000000000963390a rsp 00000000ffff9d00 error 4

Running on SuSE Linux 10 on an Athlon 64 with an nVidia 6600 and 8762 drivers.

Wow, what a great community here!

Yeah, I am in SL right now and have RenderFarClip set to 64 and UseOcclusion set to FALSE. I'll just reiterate from a posting above: hit the TAB key after typing UseOcclusion and then type in the word FALSE. You don't want to use SPACE key to then space over to where you type in the word FALSE. But so far, I have been without issue since setting these two in settings.ini for the Linux client.

I have been on I would say for 15 minutes already, but admittedly am in an area with very few items, so will see what happens when I move to a more densely populated area.

Thanks to everyone for offering helpful hints though, it was looking pretty bleak there for a while.

Update: Well I went to a more crowded area and crashed. My final WARNING messages were:

WARNING: Octree detected duplicate child center and gave up.
WARNING: Could not remove drawable from spatial group

and then I crashed.

crash crash crash crash....


everytime I crash it happens on remove_marker_file()

ex:




And then it's just ripped rudely from underneath me. And every time it's crashed on me so far it's remove_marker_file()....And just when I had everything just the way I wanted it with 1.9.x *sighs*


Tal

I've got UseOcclusion FALSE set in settings.ini and Debug Permissions on as well. Still crashing out while rezzing.

The odd thing though is that 1.10.0.32 worked for me until around 10.00pm yesterday (SLT). I logged in and out several times but logging back in today to the same location and I'm history.

Thats been my experience too, I was fine & happy after the update, then all of a sudden they started doing the rolling updates and the continous crashing started..

I found it is important after a crash to delete the cache files. I have been unable to return at times until I did that. Crashing leaves the cache files full, and WITH the rubbish in it too, apparently

That worked. For about 10 secs. Guess I'll give up on the Linux client for now and stick with Windows under Wine.

Perhaps there is an update coming out to fix these problems? Any word on that?

A change log would be cool too!

Thats part of the problem, there is no feedback whatsoever, no mention of the Linux client in any of the release notes

I just tried out the .32 client. Flew around for awhile, then crashed. Everytime I try to log back on it crashes before loading up any graphics with the same errors as seen on previous pages. As of right now .32 is bugged and unusable for me as I can't logon without it crashing again. I tried removing the cache file, but that only displayed less errors before immediately crashing.

It worked fine in the version prior to this though unusable without features like sound or texture uploading. It looks like the linux client will still be in alpha for awhile without those features. I tried uploading textures before the above crashing occured and instead of getting a dialog it just fails.

2006-05-29T17:14:43Z INFO: LLCircuit::addCircuitData for 69.25.105.40:13004
2006-05-29T17:14:43Z INFO: Adding new region (998:1000)
2006-05-29T17:14:43Z INFO: Host: 69.25.105.40:13004
2006-05-29T17:14:43Z WARNING: Octree leaf got invalid object position.
2006-05-29T17:14:43Z INFO: simulator_enable() Enabling 69.25.105.40:13004 with code 5274812
2006-05-29T17:14:43Z WARNING: Could not remove drawable from spatial group
2006-05-29T17:14:43Z WARNING: Octree leaf got invalid object position.
2006-05-29T17:14:43Z INFO: remove_marker_file()

Before you bemoan the linux alpha client, you do a little forum reading.. there has been numerous forum threads by windows and macos users with the _exact same problem_.

And, look at all the positives: aswd, efc now work for movement and flight.
Ctrl key works.
We had 1.10 at the same time as everyone else.
Bump works (not shiny though yet)
Inventory search works without any problems

Now, if you look over the linux, general and techinal forums, there's various tips for getting around crashing.. Its not ideal solution, so use the windows or macos client if you can, I think they got fixed.

That is the solution to the current Linux client - don't use it, run wine or windows native. The Linux client is broken for everybody.

Come on now, there used to be times when Linux was considered stable if it managed to compile and boot, and a minor miracle if it stayed up for the corse of the day. Depending on what sort of dev work you are doing on the kernel anymore you can enjoy those glory days still. Such a shame so few Linux users are actually developers. Oh well.

Yes the current client issues are annoying, but they aren't the end of the universe. Though I am not certain what to make of the claims that a lack of sound makes the client unusable. Half the Windows and Mac people I know turn off their sound and listen to their own music. And from what I gather about some of the music I am missing, I am a bit better off this way. The texture uploading though is an annoyance, to that I can't possibly argue. Luckily I have friends who can upload them fine, and that is kinda what friends are for, to help out when you have need.

The current crash introduced in 1.10.0.32, yes, very much a show stopper, and it painfully cripples what one can do in SL. But unusable? Hmm, Unusable for me would be Wine. When Wine attempts to engage OpenGL corrupts my video pallet, if not deadlocks my system, same with Cedega. At least in the Linux client I can login for hours on end, writings scripts, testing scripts, and talking with friends. Yah, I can't go see the sites, but I never really did that much to begin with .. something about writing code if I recall. And as for the Windows option ... I have not had a Windows installation available in 14 years, not about to go start for something as minor as this.

The SL Viewer is closed by the Linden's decision. It is their software, they can do what they want with it, it is their choice. I certainly don't go raising cain over Rock Star not open sourcing GTA. Just because something runs on Linux doesn't mean it is an open target for any other sort of treatment. If anything OpenSourc should be about respecting choices, not making demands against the choices of others. Since Linden Labs seem to not have no anyone to really focus full time on the client at current, then what we have to make due with is what we have to make due with. The alternative choice is of corse, use something else, or stop using SL at all. :hrug::

"The most vocal fanatics are usually the ones writing the least amount of code. It's hard to consider them credible or to really give a damn either way." -- Paul Mundt

For most people, there is little point logging in if you have to sit on your own in the middle of nowhere.

If your scripting I strongly urge you to run the windows client - native if you have to. There is a little known feature called copy&paste, it will make your scripting time a lot more productive.

Fixed for those of us that don't use Windows.

If you are scripting strongly I recommend dumping text files as keyboard input to the SL viewer. Then you can use your favorite SCM and editor. Oh yah, and you can do cut/paste that way as well, but you wont exacly be typing directly in the SL viewer. And that moving the mouse between the windows .. wew .. thats some work I tell yah.

All very true, but its not as easy to debug a script that way.

Not certain I understand how that is any different then debugging a script via regular cut/paste. Using XSendEvend or XTest to dump an X clipboard as keyboard input to the SecondLife viewer simply gives you a one-way paste operation. Yes you can't cut from SL and paste back into Linux, but you can easily do simple things like make an sl-upload script that takes a file and turns it all into keyboard input on the SL window and have it dump the file directly as keyboard input into a script. xse is one such tool that can be used to write such a script, but sending text as "xse -win 'Second Life' '<Key>h' '<Key>i' '<Key>Return'" is a bit more verbose a translation then I think I would be happy with. xse is mostly useful for playing with learning how XSendEvent(3X11) works anyway. XTEST tends to be a bit better for that sort of thing, but it isn't supoprted by all versions of X11 as it is a fairly new interface. On the other hand .. I don't suspect old X11 installs would be so much a problem for the average Linux SL user.

Either way, you edit your code locally in any editor, keep it in SVN, Arch, TLA, CVS, BZR, whatever. Then sl-upload and test it. Minus the ability to copy back from SL to X11, I am not certain I follow why debugging is made any more or less difficult. It certainly keeps your script inventory a bit more cleaned up on the SL side as you can just keep a single copy of any script and not try to do the whole manual tracking of versions stupidity on the SL side. On lagging Sim's I suspect you might have an issue with keyloss, and without feedback from the SL client on this, you end up sort of screwed for flow control. Its almost like the ymodem days all over again.

I suppose it is also possible to create an invisible window that hovers over SL and passes through all events except the paste event and just XSendEvent/XTEST the clipboard as keyboard input. Would be fairly natural that way for those who primarily think of doing things via a mouse interface and get scared of the command line.

Either way, there are a huge number of tools that already exist that have example code of doing this sort of thing. gok, dasher, xvkbd, xkbd, ect..ect.. The only difference here is that these tools are watching for a specific mouse selection on specific widgets and dumping the correct events on a per key selection from the mouse. In many ways, setting up a text input region and just dumping all input text as events as they come in is quite a bit less code. The most complicated work is the text to event translation. See XStringToKeysym(3X11) and friends.

Happy Hacking

I managed to get the program working by upgrading wine. Its running fine. The new versions of wine work fine.

Err, the rest of your post follows on what I think is a wrong assumption. I believe ninjafoo was talking about the fact that you can Copy/paste from SL to SL. The debugging speed has to do with eliminating a step to compile. Your method is this:

1) write code in preferred editor (preferably emacs )
2) upload to SL
3) compile
4) observe syntax errors, goto 1

Whereas, with native copy/paste using the native client, we get:

1) write code in SL editor
2) compile
3) observe syntax errors, goto 1

It's faster because you can work out both compile- and run-time errors more rapidly. You see the syntax error, the SL editor takes you to the appropriate line IIRC, and you fix it. You compile, drop the script in an object, see the run-time error, fix it. You save tons of "faux-uploading" operations that just make the whole process take longer.

Now, if there's an LSL syntax checker sitting around that I don't know about, I take half of that back. But the problem still happens at run-time errors.

Odd .. vim highlights syntax errors before the upload. Doesn't emacs have a syntax file for LSL yet?