Memoirs of a Memory Leak

Written By: Will Burns | Andromeda Media Group
SecondLife: Aeonix Aeon | Pixel Labs
Twitter: http://www.twitter.com/darianknight

About twenty years ago, Chip Morningstar and F. Randal Farmer described the strange idea that in the future, virtual environments would no longer handle being centrally located, but instead a method for decentralization would need to be employed if we were ever to break the glass ceiling that is bandwidth and co-current users. Of course, I am referring to the classic writing of Lessons Learned From Lucasfilms Habitat. Later though, something even more remarkable happened in the budding industry.

It was not the evolution of the virtual environment, but by some strange twist of fate, quite the opposite. One could argue that the graphics and complexity of the software have indeed been in an upward evolution since the early 1990s, but there is an underlying issue (or more appropriately multiple issues) which continue to nag and plague systems even to this day.

In the race forward for virtual environment dominance, the lessons learned from habitat have been discarded to the wayside as a footnote in history. Instead, we see continued creation of server architecture which not only is decidedly centralized, but further so than predecessors. This is in stark contrast to the warnings and valuable insights given to us from the early pioneers.

Fast forward to the end of 2010, and we see datacenters running night and day to accommodate not only co-current users, but now the pre-processing and streaming of the virtual environment to those users. It is little wonder why the evolution of complexity for these environments is undoubtedly overwhelming the bandwidth limitations and back-end. In this manner, the industry has a metaphorical memory leak, which is to say they simply forgot those lessons and act truly bewildered and perplexed when the scenarios described by those lessons suddenly manifest.

In so much as Second Life, there too exists a literal memory leak to go along with their metaphorical memory leak. Viewer 2, for all the good it brings, is currently crippled by an unfixed memory leak which leads to the viewer suddenly, and without warning, quitting.

When we think of a program quitting, we often imagine the notion of it showing a dialog saying “Do you really wish to quit this program?” and a handy Yes or No button. In more severe forms, we could even say that a program suddenly quitting would default to a crash logger. Even so, in most instances, this is not the case.

What Viewer 2 suffers from is rushed and error prone programming. With the layoff of 30% of the Linden Lab employees, those who are left are possibly ill-equipped to sort through the source code for Viewer 2 and make timely corrections. With the increased schedule of agile development added to that scenario, we begin to understand that many of these crippling issues will remain unfixed for the foreseeable future.

In so much as the idea of the literal memory leak for the viewer, whenever it manifests it literally shuts the entire viewer down without notice. There are no dialogs. There is no crash logger (unless you have enabled Debug OpenGL), and there are no answers. The viewer will simply quit.

I’ve reported something similar in the JIRA a number of months ago concerning the minimized chiclet conversations and a possible memory leak which resulted in the same scenario. The longer they remained idle in the bottom bar, the higher the risk that clicking them to restore the IM window would result in crashing the viewer in a force quit scenario.

Months later, and the memory leak seems to have found another outlet in the viewer, except this time it isn’t tied to instances of instant messages, but literally using the viewer in the environment for too long. Looking into carious JIRA posts on related issues, some have tied this memory leak to the viewer ignoring the VRAM limit, causing it to fault and crash.

Whatever the reason, I still use Viewer 2 codebase, however I do so a bit more sparingly. When I absolutely need to have reliability, I usually opt for Phoenix. When I need to have shadows and lighting, I then turn to Kirsten’s viewer S20. Of course in that mix of installed viewers I also have the latest Second Life Snowstorm Development build installed, as well as the standard Viewer 2.0

Will I abandon Viewer 2 as a result of this memory leak? No more than I would abandon Second Life itself for having a metaphorical memory leak when it comes to lessons of the past.