[opensource-dev] Help with Linux viewer-cleanup viewer

Nat Goodspeed nat at lindenlab.com
Tue Oct 11 13:36:07 PDT 2016


I'm writing to ask for help from Linux open-source developers on a viewer
infrastructure project I've had going for some months now.

The motivation is that our hard-coded sequence of
LLSomeStaticClass::cleanupClass()
calls is fragile. As we maintain the viewer, we keep having to debug
shutdown crashes due to subtle changes in the dependencies between such
classes.

It occurred to me that LLSingleton (and Singleton in general) is already a
mechanism to construct resources in correct dependency order. If we extend
LLSingleton to track those dependencies, we could then *destroy*
LLSingleton instances in reverse dependency order as well.

So the Big Picture vision is to incrementally convert the many viewer
static classes -- "classes" whose methods are all static, and whose data
are all module-scope static variables -- to LLSingletons instead, and clean
them all up in one swell foop in dynamically-determined dependency order at
viewer shutdown.

Naturally that will require a good deal of refactoring of existing
functionality:


   - Change LLSomeStaticClass to derive from LLSingleton<LLSomeStaticClass>.
   - Make its methods non-static.
   - Move its data from module-scope static variables to non-static data
   members. (We may want to use the pImpl pattern for some of these classes to
   keep voluminous data declarations out of the header file.)
   - Change callers from LLSomeStaticClass::method() to
   LLSomeStaticClass::instance().method().


However, this viewer repository does not yet start down that path. This
viewer seeks only to equip the LLSingleton machinery with the ability to
track inter-LLSingleton dependencies, and destroy LLSingleton instances in
reverse dependency order.

Along the way I had to clean up some, mmm, irregularities in the way
certain LLSingletons were being used. That led to pervasive changes to
normalize the way viewer LLSingleton subclasses are declared.
https://bitbucket.org/lindenlab/viewer-cleanup/branches/compare/lindenlab/
viewer-cleanup:tip%0Dlindenlab/viewer-release:default#commits

I claim that what I have in hand is quite close to the initial goal: this
viewer *does* track LLSingleton dependencies, and does destroy them in a
correct order. The Windows and Mac viewers seem robust.
http://automated-builds-secondlife-com.s3.amazonaws.
com/hg/repo/viewer-cleanup/rev/320485/index.html

However, I am distressed to report that the Linux viewer gets partway
through login -- up through STATE_AGENT_WAIT -- and then either hangs or
crashes.  :-(
https://jira.secondlife.com/browse/BUG-40596

I've observed two such crashes in LLUICtrlFactory::createWidgetImpl<
LLAccordionCtrlTab::LLAccordionCtrlTabHeader>(). I don't know if we could
say that it *always* crashes exactly there -- too few data points.

I believe it's crashing in malloc(), which would suggest that the heap has
been corrupted, which implies that the actual bug happens some time *before*
then.

I totally believe that the bug is my fault. I simply don't yet know where
it happens or why.

This is where I'm asking for your help. I'm not at liberty to do a deep
dive into the Linux viewer. Yet I would be terribly sad to have to abandon
this effort entirely. I believe it can be foundational for a more robust
viewer on every platform.

Thank you for your insights!

-- 
NAT LINDEN | Senior Software Engineer | Real Life: Nat Goodspeed LINDEN LAB
| Create Virtual Experiences <https://www.lindenlab.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20161011/af62de72/attachment.htm 


More information about the opensource-dev mailing list