• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
MAINTENANCE ANNOUNCEMENT - JIRA will undergo maintenance starting 1:00am PDT through 3:00am on Saturday 2010.03.20. Please do not enter issues during this time as the system maybe restarted.
Issue Details (XML | Word | Printable)

Key: VWR-12161
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: WorkingOnIt Linden
Reporter: Chalice Yao
Votes: 7
Watchers: 5
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR

1.23 Trunk: avatar_skeleton.xml cannot be parsed

Created: 22/Feb/09 11:47 PM   Updated: 23/May/09 07:09 AM
Component/s: Avatar/Character, Crashes, Internationalization
Affects Version/s: Source code
Fix Version/s: 1.23 Release Candidate

Time Tracking:
Not Specified

File Attachments: None
Image Attachments:

1. screenshot-1.jpg
(120 kB)

2. screenshot-2.jpg
(68 kB)

3. screenshot-3.jpg
(81 kB)

4. screenshot-4.jpg
(74 kB)

5. screenshot-5.jpg
(88 kB)
Environment: Windows XP 32bit SP3, nVidia GeForce 8800GT, Core 2 Quad q6600
Issue Links:
Duplicate
 
Parent/Child
 
Relates

Last Triaged: 25/Feb/09 09:28 AM
Linden Lab Issue ID: DEV-27969
Linden Lab Internal Branch: viewer/viewer_1-23


 Description  « Hide
Greetings,

The current 1.23 trunk (and 1.23.0 viewer) crashes during the login procedure, as it fails to parse the avatar_skeleton.xml file properly.

  • The file itself seems valid, and I've tried those of the current 1.23 trunk revision, as well as those of earlier ones.
  • The exact point of failure is in llmath/v3math.cpp, in the method LLVector3::parseVector3, when the positional values of teh first bone, mPelvis, get read;
  • The buf std::string variable is filled properly with the position values of "0.000 0.000 1.067", however the sscanf() method fills the declared vector v with zeros and returns void, hence causing the method to return FALSE and the client to stop parsing.
  • Even when streaming the values into F32 variables and setting the vector with them, shapes fail to load properly once the viewer is running.
  • NOTES: the actual RC0 is affected by this too i have some comments about this crash.

Temporary work around:
1 - Open the Windows control panel
2 - Open "Regional and Language options"
3 - Click "Customize" to change the land specific settings
4 - change the Decimal Symbol from comma to period
5 - Try a restart of the viewer.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Robin Cornelius added a comment - 23/Feb/09 04:19 AM
Please can you confirm your system locale, sscanf() is locale dependent for its decimal point separators and this has been an issue in the past when the locale was not set internally to "C" at this stage. Some locales use "," comma for a separator, eg many European ones other than English and this will cause parsing errors if the local is incorrect at this stage

Chalice Yao added a comment - 23/Feb/09 05:09 AM
I shall check when I get back to my own PC.
Previously the locale has not been an issue, be it in the 1.22 code or the early 1.23 trunk, so if it's that causing it I presume some locale setting/checking is failing since the last update of the code.

Chalice Yao added a comment - 23/Feb/09 11:31 PM
A setlocale(LC_NUMERIC,"C"); indeed fixed things.
So yes, a confirmed issue with setting the needed locale in that revision.

Robin Cornelius added a comment - 24/Feb/09 12:58 AM
Seems also to be windows specific, cannot reproduce on trunk on a Linux build

Thomas Shikami added a comment - 28/Feb/09 02:24 PM
It looks like SL-35450 applies to windows as well. I modified llmediaimplllmozlib.cpp to push/pop the locale for windows as well. Changing the #if LL_LINUX into #if LL_LINUX || LL_WINDOWS, the login works now.

An explanation why this behaviour did not happen before might be the change of linking expat and the other libraries to dll-msvcrt instead of statically. As xul.dll sets locale in msvcr80.dll. Before 1831 expat had it's own locale variable, because linked statically. Since 1831 expat shares the locale variable with msvcr80.dll.


Alissa Sabre added a comment - 31/Mar/09 06:20 AM
I believe this is rather an internationalization issue than character/avator issue, so added the component.

Yann Dufaux added a comment - 21/Apr/09 10:34 AM - edited
i have the same probleme here:

009-04-21T09:12:36Z INFO: LLAppViewer::loadSettingsFromDirectory: Attempting to load settings for the group Global - from location User
2009-04-21T09:12:36Z INFO: LLAppViewer::loadSettingsFromDirectory: Loaded settings file C:\Documents and Settings\Yann\Application Data\SecondLife\user_settings\settings_publicnightly.xml
2009-04-21T09:12:36Z INFO: LLAppViewer::initMarkerFile: Last exec LLError crashed, setting LastExecEvent to 2

i hope to test this version! thank


Wuf Shirabyoshi added a comment - 26/Apr/09 01:19 PM
folks,

This bug is from februari, and it is still not fixed. I live in europe (sorry for that), but i have to set my regional settings to US to use the nightly build.
Could someone assign this bug????

thanks in advance


Ramzi Linden added a comment - 28/Apr/09 04:08 PM
We are definitely working on this. In fact, we believe we have this bug now Fixed-- but we are testing to be sure the fix is working on all conditions.

This bug will still appear in Release Candidate 1.23 RC0 , but we will have it fixed in a future Public Nightly and in RC1.


Jadzia Korhonen added a comment - 30/Apr/09 09:09 AM
Hi

I think you should not call it a "Release Candidate" when you KNOW that it can not been used by most people that do not speak english. Even a Beta Version should not have such an easy to find error.
The work around is not very usefull because I can not use many Programs with it.

Loocking forward to RC1


Vryl Valkyrie added a comment - 30/Apr/09 07:42 PM
First of all, this is bad advice. Please do not follow the fix provided by Linden Lab. Do NOT simply change the decimal symbol. The better solution is to do this:
[img]http://www.vryl.eu/euro1.jpg[/img]

[img]http://www.vryl.eu/euro2.jpg[/img]

[img]http://www.vryl.eu/euro3.jpg[/img]

[img]http://www.vryl.eu/euro4.jpg[/img]

[img]http://www.vryl.eu/euro5.jpg[/img]

Result, no crashes.. no problems with system.. logs on very fast. My system is French but same principal for all other users having this issue.

Not sure if I did it correctly or not but just added my fix to the jira here:

https://jira.secondlife.com/browse/VWR-13106

I also posted my fix in XstreetSL here: https://www.xstreetsl.com/modules.php?name=Forums&file=viewtopic&t=104874
Sorry, i'm new at using the jira so sorta put this issue all over.. a support ticket in concierge.. on the forums.. then finally here created a new issue and then here found this comments area.. oh well, live and learn.

Anyway, please use the fix that I provided. It is the correct way to resolve the issue for now. Do NOT simply change the decimal symbol This can cause issues with your system. Follow my steps.. I have included screenshots. Hope this helps.


Vryl Valkyrie added a comment - 30/Apr/09 07:44 PM
Actually, it is changing the "format" not "region".. that is a typo on the screenshot.

Ramzi Linden added a comment - 05/May/09 12:42 PM
Vryl, thanks for posting a better workaround method.

Hopefully this bug will be completely behind us (eradicated for all residents) in the upcoming RC1 which is due out very soon.


Thomas Shikami added a comment - 08/May/09 02:09 PM
Affects Second Life 1.23.0 (2232) May 8 2009 08:52:46 (Second Life OSS) as well

Yann Dufaux added a comment - 08/May/09 05:26 PM
I confirm its fixed since! 1.23rc1 good work!! thank you again!

Thomas Shikami added a comment - 23/May/09 07:09 AM
This is fixed in 1.23 RC2. I can login without troubles on a German system. Decimal point is , (comma)

closing this again.