SL project reports week 17 (2): COF corruption and SSB/A

At the Open-source Dev meeting on Wednesday April 25th, Whirly Fizzle raised a concern on the status of JIRA SVC-7653, which relates to Current Outfit Folder (COF) corruptions leading to an avatar being unable to log-in to Second Life which may have an impact on the forthcoming Server-side Baking / Appearance switch-over.

The problem was first publicly reported by AngusGraham Ceawlin in February 2012, and at the time became of the focus of a campaign to Free Angus. After a total of some 63 days unable to log-in and with the (particular) support of Whirly herself and Nicky Dasmijn, Paspund Resident and Izzy Linden, Agnus was indeed freed. However the problem has become a matter of concern again because SVC-7653 remains marked as “unresolved”, and a workaround developed for it looks set to be “broken” when SSB/A goes live.

The "Free Angus campaign poster" produced by Sparkles Alchemi and used in a number of blog posts in early 2012 to highlight Angus' situation
The “Free Angus campaign poster” produced by Sparkles Alchemi and used in a number of blog posts in early 2012 to highlight Angus’ situation

The COF Corruption Issue

When this particular issue occurs, the user has no clear indication that there has been an inventory corruption specific to the Current Outfit Folder. There are only tell-tale clues, which Whirly Fizzle documented (on behalf of Kitty Barnett) as being:

  • Only one account is affected
  • A crash or timeout disconnect will occur at log-in, usually around “Downloading clothing…”
  • The affected account will crash/disconnect on any V3-based viewer or a viewer that uses COF
  • A clean install, cache clear, replacing outfit on a non-COF viewer will not fix the problem
  • The associated viewer logs will usually show:

INFO: newview/llappearancemgr.cpp(1998):LLAppearanceMgr::updateAppearanceFromCOF : starting

Generally (but not always) followed by numerous warnings:

WARNING: newview/llappearancemgr.cpp(2891) : WearablesOrderComparator::operator(): Warning # 0: either item1 or item2 is NULL

Followed by a crash or a timeout.

The Workaround

While LL’s support staff do have scripts to deal with various inventory corruptions and issues, under current rules, they will only run these scripts for Premium accounts. While it may be possible to get further assistance from the Lab if you’re not a Premium account holder, it is certainly going to take a good deal longer to gain assistance. As a result, Kitty Barnett developed a workaround for non-Premium members, which Whirly included in her comments on SVC-7653:

  • Use a viewer which does not have COF support and log-in to SL. Currently, Imprudence is possibly the most easily obtainable such viewer
  • Replace outfit with a Library avatar. Thus must be a complete outfit change (every layer / attachment)
  • Log out of the viewer
  • Launch a TPV which uses the VerifyInitialWearables debug setting (such as Catznip, Exodus, or Firestorm – note that the official viewer does not have this setting)
  • At the log-in splash screen:
    • Go to the top menu bar and select Me/Viewer > Preferences > Advanced and tick Show Advanced Menu
    • From the top menu bar, go to Debug > Debug settings > VerifyInitialWearables and set it to TRUE
  • Login to SL.

This should result in a message being sent to the server by the viewer using the VerifyInitialWearables which will result in the COF corruption being “fixed” and the avatar being able to log-in successfully to SL. A change of outfit should then verify that all is well.

The Workaround and SSB

Tests carried out by TPV developers have shown that the VerifyInitialWearables message sent by the viewer is ignored by the SSB/A servers. This has resulted in concern that unless the Lab have developed a resolution for this issue,  anyone encountering it once SSB/A is “live” will not be able to utilise the documented workaround, and they’ll effectively be unable to log-in to Second Life unless they are a Premium member (or upgrade).

The matter has apparently been brought to the attention of the SSB/A team (led by Nyx Linden), who have been engaged in a wide range of inventory updates and associated work, “More than they hoped would be needed,” as Oz linden put it at the Open-source Dev meeting. But whether or not their work extends to fixing this particular problem is unclear. SVC-7653 remains “unresolved” but inactive – so it is perhaps possible a fix has been developed internally by the Lab without SVC-7653 being updated. However, until greater clarification is given, this is likely to be a subject of note at User Group meetings which deal with SSB/A matters.

Related Links

3 thoughts on “SL project reports week 17 (2): COF corruption and SSB/A

  1. huppps i never heard about this bug, glad i’m premium still!
    But really lets hope LL will find a fix for All.

    Like

  2. If this bug is impact many people on some point the get a hugh problem. the just need to stop been silly and give better support to non premium. Ir more people run away.

    Like

Comments are closed.