Lockups again with 1.10.3

Thanks for the tips Theora. I'll try those out and post the results here later on.

I did a quick cat /var/log/Xorg.0.log | tail before and after crashing the client to see if there would be anything promising. No change in output, so X.org isn't throwing any errors on this one.

I'm not sure how intermittant my problem is. As I said, it's happening every other time the client is run and the problem started with 1.10.3.3. To test my perceptions, I just did a set of runs, changing which client version I ran at a whim (pseudo-randomly)

Here's the result of the trial runs just now. Note that "runs" means that the program gets as far as the login screen (At which point I quit the program to move on to the next run) while "lock" means that the bug expressed and I got only a black window and had to kill the process before moving on.

Trial 1 - 1.10.3.3 - lock
Trial 2 - 1.10.3.4 - lock
Trial 3 - 1.10.3.3 - runs
Trial 4 - 1.10.2.2 - runs
Trial 5 - 1.10.3.4 - runs
Trial 6 - 1.10.2.2 - runs
Trial 7 - 1.10.3.3 - lock
Trial 8 - 1.10.3.4 - lock
Trial 9 - 1.10.2.2 - runs
Trial 10 - 1.10.3.4 - runs
Trial 11 - 1.10.3.3 - runs
Trial 12 - 1.10.2.2 - runs

Parsing that by version number instead of time yields the following: (Note that both 1.10.3.3 and 1.10.3.4 begin with a lock. This is because my routine is to go onto other things after logging out of SL and not bother doing my "run-crash/kill/run-good to clear the bug" routine until the next time I want to use SL.)

Trial 4 - 1.10.2.2 - runs
Trial 6 - 1.10.2.2 - runs
Trial 9 - 1.10.2.2 - runs
Trial 12 - 1.10.2.2 - runs
------------------------
Trial 1 - 1.10.3.3 - lock
Trial 3 - 1.10.3.3 - runs
Trial 7 - 1.10.3.3 - lock
Trial 11 - 1.10.3.3 - runs
------------------------
Trial 2 - 1.10.3.4 - lock
Trial 5 - 1.10.3.4 - runs
Trial 8 - 1.10.3.4 - lock
Trial 10 - 1.10.3.4 - runs

I should do a longer trial, but this seems to bear out my perception. There's a state stored somewhre in the SL directory structure that's causing 1.10.3.3 and 1.10.3.4 to crash on exactly every other run for me. 1.10.2.2 appears unaffected.

One thing I noticed is, unlike you, I get the following after the message where it locks on your system:

2006-06-18T21:44:00Z INFO: Viewer Digest: 00000000-0000-0000-0000-000000000000

i.e. no numbers at all.. I wonder if this is significant?

I went through your other suggestions as well, Theora. I also tried the Nvidia driver module instaed of the AGPGART module I usually use. None of these tests appears to make any difference or point to a cause of the bug. The every-other-run nature of the bug continues as in my previous post.

Here's the log of my observations:

Option "NvAGP" 0
# i.e.  AGP turned off
#Normally I use Option "NVAGP" 3 (AGPGART module)
# Restarted X (of course)
# All trials in this file/post done with Second Life Linux Alpha 1.10.3.4

Trial 13 - lock
Trial 14 - runs
Trial 15 - lock
Trial 16 - runs
Trial 17 - lock

Option "NvAGP" 1
# i.e. AGP with Nvidia module
# Restarted X (of course)

Trial 18 - runs
Trial 19 - lock
Trial 20 - runs
Trial 21 - lock
Trial 22 - runs

# Removed nvidia-glx drivers (8762)
# Installed nvidia-glx-legacy (7174)
# Option "NvAGP" 1 still
# Restarted X (of course)

Trial 23 - lock
Trial 24 - runs (logged in to check "Help->About" and verify legacy driver version 7174. Verified)
Trial 25 - lock
Trial 26 - runs
Trial 27 - lock

# Back to my original preferred config
# Option "NvAgp" 3 and nvidia-glx driver (8762)
# Rebooting machine to try memtest86+

One full pass of memtest86+. 42 minutes elapsed. 0 errors.

#Reboot.

It could be! In SL, when you select "Help->About Second Life" to view system info, etc.. does the Viewer Digest still appear as a string of zeros to you there?

If anyone else can check up on this behavior, it might be the beginning of a diagnosis for this. Does anyone know what the Viewer Digest is?

-Bones

Edit: I have the client running now, and looking at lastrun.log (which is actively being added to as I type) I have a non-zeros viewr digest line:

2006-06-18T21:58:55Z INFO: Viewer Digest: aedcebd7-7bcc-e2b4-cfcf-3844a75e6c52

(A few digits changed to protect the innocent.. or whatever the Viewer Digest is. )

Yep.. still 0's... weird!

total giberish so far sl latest version and the upgrade to the latest version locks my whole pc not straght away sometimes forcing it to restart itself have done a complete fe format today second in a week havent installed anything only latest gforce drivers and directx 9.c and im getting real sick of the lock outs anyone have any clue ????

If this is really the case, it should not be too hard to track down.

Make a bash script that copies your directory every time you run it:

#!/bin/bash
cp -rf ../SecondLife* ../SLbackup
./secondlife

then after a successful run, check the backup version always works

rm -rf SecondLife*
mv SLbackup Secondlife*

and run the script again..

If this is true, then do a diff on all the files compared to a dir structure when it does not start:
(archive the SLbackup dir somewhere else and then keep running the script until it fails

diff -r SLbackup SLbackup_archive

and note which files have changed.

Great tips, Theora! I might have a break on fixing this!

I made a backup of the SL directory after a crash. Then ran the original, which predictably worked, and Quit.

Now, to see what changed.....

bones@gecko:~ $ diff -qr SLBackup SecondLife_1_10_3_4
Files SLBackup/lastrun.log and SecondLife_1_10_3_4/lastrun.log differ
Only in SLBackup/SecondLife/cache: data.db2.x.24318302
Only in SLBackup/SecondLife/cache: index.db2.x.24318302
Files SLBackup/SecondLife/logs/debug_info.log and SecondLife_1_10_3_4/SecondLife/logs/debug_info.log differ
Only in SLBackup/SecondLife/logs: SecondLife.exec_marker
Files SLBackup/SecondLife/logs/SecondLife.log and SecondLife_1_10_3_4/SecondLife/logs/SecondLife.log differ
Files SLBackup/SecondLife/logs/SecondLife.old and SecondLife_1_10_3_4/SecondLife/logs/SecondLife.old differ
Files SLBackup/SecondLife/user_settings/settings.ini and SecondLife_1_10_3_4/SecondLife/user_settings/settings.ini differ
bones@gecko:~ $

Tried copying those files from the (known to work on next-run) backup.

lastrun.log -- No go
/SecondLife/logs/debug_info.log -- No go
/SecondLife/logs/SecondLife.log -- No go
/SecondLife/logs/SecondLife.old -- No go
/SecondLife/user_settings/settings.ini -- No go

Copied over /SecondLife/cache/data.db2.x.24318302
and /SecondLife/cache/index.db2.x.24318302 together
no go

Copied over /SecondLife/logs/SecondLife.exec_marker
Success!!

SL boots every time when I copy over SLBackup/SecondLife/logs/SecondLife.exec_marker Put the cp command in the secondlife script and she comes up every time now! Woo!!

/SecondLife/logs/SecondLife.exec_marker is an empty file... 0 bytes.

So, the bug looks like either:
A.) I'm missing /SecondLife/logs/SecondLife.exec_marker when it should be around. SL deletes it at some point when it shouldn't.
or
B.) Second Life shouldn't crash when /SecondLife/logs/SecondLife.exec_marker isn't present, but it does anyway.

Does anyone else have /SecondLife/logs/SecondLife.exec_marker in their SL directory structure?

Kelseigh, does putting an empty file named SecondLife.exec_marker in the /SecondLife/logs/ subdirectory of your SL install fix the client for you?

You rock, Theora!

-Bones

Glad it helped, but it's quite mysterious....



Not there on my system!

Just to check: when you uncompress a fresh version of SL, do you make any changes to the config file, or copy over an old one from a previous version?

I usually run without any changes (at least for the first few times) to make sure it works before I start fiddling around with it! (I am sure you do the same, but just to check!)

Another odd thing I have noticed: SL does not detect my CPU correctly. It says Can't get terse CPU information in debug_info.log

Just one other off-chance thought I had: Did you use a "real" libdb2.so or did you link libdb2.so to a version of libdb3.so?

My usual habit is to log in and run around at least once before copying over my settings. I usually migrate my settings by hand.. only the things that I usually put in. Graphics card memory, window size and position, etc.

Perhaps I made a mistake in my usual habits though. I'll check that out.

-Bones

Edit: Update

For me, SL crashes the first time on a clean install (untarring) of the archive. I've tried a few different untarring methods and re-downloaded the archive from the SL website. Same result: SL crashes on the FIRST run(as it did/does for Kelseigh), and begins the every-other behavior from there.

On untarring the /SecondLife/logs directory is there, but empty.

Interesting. When I looked, there's already a file there by that name, and if I delete it, it creates a file by that name. Looking back, 1.10.2 doesn't have the file at all. Noting, of course, that 1.10.2 worked perfectly. I haven't copied any files to this new install, although that's my normal procedure.

Oh, and I tried those other suggestions. There's nothing weird that I can see in /var/log/Xorg.o.log, and uninstalling/reinstalling the current nVidia drivers didn't make any difference. Unfortunately, there doesn't seem to be a NvAGP variable in my xorg.conf file.

The rest of the suggestions I can't figure out how to do. Ah, well.

I am starting to run out of ideas.. I think the file may be a red herring. It seems to be created when SL runs, so if it terminates abnormally, the file will still be there. I can't really explain how it helps bones to run SL correctly.. Although doing some experiments, it seems that with the file present there is one

INFO: QUEUED THREAD STARTING

message immediately when SL starts up, whereas when it is not there, there are four

INFO: QUEUED THREAD STARTING

messages...

Perhaps this could be a pthread problem??? Anyone more knowledgeable than me about this help? Is it a problem with glibc version? I notice in the secondlife script it says:

# MALLOC_CHECK_=0 is a temporary workaround for some glibc installations

Really don't know if this could be something to do with it!!?

Anyway, I guess it would be worth reporting the bug with the gdb backtrace. Sorry for not being more help.

Edit: I notice from the backtraces that Kelseigh and Bones have different glibc versions installed.. so maybe this could explain the problem. Is it possible for you to (safely) upgrade glibc??? On my system I have libc6 version 2.3.6

Just add

Option "NvAgp" "0"

somewhere in your xorg.conf file and restart X (ctrl-alt-backspace)

What happens for me is that the file is deleted when SL terminates normally. When the client crashes, the file is still there and thus the client will start normally next time.



I've got version 2.3.6 as well. 2.3.6-0ubuntu20 right now.

I've noticed that ever since I've dist-upgraded to Ubuntu 5.10 and now 6.06, I somtimes get several "/xyz/abc/yaddayadda.so is not a symlink" type messages when I do an `apt-get dist-upgrade'. I'm rather fond of the fact that I've dist-upgraded the system through three major version changes, but maybe there are subtle things beginning to fracture inside.

Dunno,
-Bones

That's weird, I hadn't noticed that I'm running an older version of glibc.

I updated to 2.3.9, and tried running SL without that file, but no improvement. It still locks in the same place. I just can't figure out why 1.10.2 worked and 1.10.3 doesn't.

did you try the disable agp thing?

Yeah, I did. No dice.

Hmm I'm afraid I'm really stuck now...

Have you tried the preview client yet?

Second verse, same as the first...

Still getting the exact same problem. The only thing I can possibly think of is that somehow it objects to my video card. I can't imagine why, it's a GeForce4 integrated, which has never been an issue until now.

Strange.

Um...this may sound a bit dumb (there are no stupid questions, except this one), but how do I report a bug? Is there some procedure I have to go through?

It's possible.. You could test it further with a different distro!!! (perhaps a live-CD based one to make things slightly less destructive?) I still have the feeling it is something with your system: maybe something running in the background, maybe running out of RAM, maybe incompatible libraries.. it is really frustrating...

But, anyway, the best way to report a bug is on the bug list sticky (above).

The issue is still present with 1.10.4.4 for me (clean untar, no customizing yet)

Fiidlesticks.

-Bones

Just a shot in the dark:

What kernel version are you running?

uname -r

2.6.16-1-k7

2.6.13-15.10-default

2.6.15-25-k7