[sldev] Emerging top crashers in Snowglobe 1.1

[Ann Otoole]

Robert may be on to something here. 

The snowglobe client can use the same directory as the production viewer.

However all settings for all clients are all in the same roaming folder and changes to stuff in one account affects all accounts.
This tends to make me think the SL client is only safe for one version and one account per computer. 

Shouldn't it be such that each major version (Snowglobe, Secondlife, etc.) each has their own cache and settings directories and that each account on each client version has it's own separate cache directory? What happens when -multiple is used? How does SL keep track of what texture cache to hit if they are all the same?

I made a seperate directory for snowglobe cache and brought up 3 sessions using the -multiple parameter. In this new cache directory one of the clients wrote a directory for one of the account names. This was the first client that was loaded. The 2 subsequent sessions did not write a user directory in the cache directory. The fact this user directory was created there seems to be an issue since all of the clients all use the appdata roaming secondlife directory for settings by account stuff. Meaning all clients seem to share stuff across main and snowglobe. However the main viewer did not pick up the setting to use the new cache directory due to snowglobe using a different settings xml file.

Something about that user name directory being created in the cache directory for snowglobe seems odd. 
Why was it created when it is supposed to be using the directory structure identified as for logs?.

Note that I can clearly see snowglobe is using a different designator in the cache files so if there is a conflict here it would have to be some snippet of code not looking in the right one if they are all piled in the same directory. I also see that there are different cache files per user with the second user getting a .1 extension, third gets a .2 extension, etc. These extensions were appended to the files created after a cache clear, move cache directory, then load each account and fetch inventory. 

Load account A and data.db2.x.8869 and index.db2.x.8869 is created 
Load account B and data.db2.x.8869.1 and index.db2.x.8869.1 is created 
Load account C and data.db2.x.8869.2 and index.db2.x.8869.2 is created 

This is where it gets ugly. If I cleared cache and loaded clients in order of A, B, and C, then exit all, and load C then the files created by A are in use by the client.
Seems to me the files created by account C should be in use when account C is loaded by itself.

I see  name.cache is shared across all sessions. Is this wise? What are all these names in this file anyway lol.

I am beginning to think it is unsafe for anything but one client version and one user account per computer. Well unsafe is too strong.
Let's just say you might experience interesting results by trying to run multiple accounts on the same computer.








________________________________
From: Robert Martin <robertltux at gmail.com>
To: SLDev Mailing List <sldev at lists.secondlife.com>
Sent: Wednesday, August 5, 2009 2:36:50 PM
Subject: Re: [sldev] Emerging top crashers in Snowglobe 1.1

Sideways issue to this is
How is the profile data folder controlled??

Some of the issue may be from folks running multiple clients with a
single profile folder
(on my own system i have SL 1.23 , SnowGlobe 1.1.2?? and Emerald all
pointed at the main secondlife profile data folder (oh and until
vwr-6199 is updated to SG/1.23 i also have 1.20.6 in the mix)

some of the crashes may be from a tiny bit of skew in the cache
handling so if we could have the profile redirected to say
%apdata%/SnowGlobe that may be useful for bug chasing.
-- 
Robert L Martin
Please tell me there is some XML file that can be edited and its not
baked in the bin
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090805/5847a389/attachment-0001.htm