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>
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges