[#VWR-2782] Memory leak - LLMotion objects not released as much as they are created

1. Second Life Viewer - VWR

Memory leak - LLMotion objects not released as much as they are created

Created: 18/Oct/07 02:21 AM Updated: 09/Jul/09 11:38 AM

Return to search

Component/s:

Performance

Affects Version/s:

1.18.3.5, 1.22 Release Candidate, 1.23

Fix Version/s:

None

File Attachments:

9999_undo_linden_llmotions_from_voice.patch (16 kB)

Environment:

« Hide

Tested on Mac OS X (PPC) for version 1.18.3.5
Tested on Linux (AMD 64) for version 1.22
Tested on Mac OS X (Intel) for version 1.24.2

Issue Links:

Relates

This issue Relates to:

VWR-2997 Second Life Client Severe Memory Leak Problems and Repeated Crashing - SL Use Now Becoming Impossible/Unbearable

VWR-2840 Big memory leak: SL absolutely unusable in 5 minutes

~~VWR-6800~~ Memory leak in llcharacter/llmotioncontroller.cpp

This issue is related to by:

~~VWR-2689~~ Suspect memory leak on Mac (Intel Core Duo, OS 10.4, TIGER)

Description

« Hide

There seems to be about 100 kb of unreleased memory per LLVOAvatar creation/destruction cycle.

Added the following lines to llcharacter/llmotion.cpp :
long numMotions = 0L;
in constructor LLMotion::LLMotion( const LLUUID &id ) : numMotions++;
in destructor LLMotion::~LLMotion() : numMotions--;
and in newview/llvoavatar.cpp :
extern long numMotions;
in LLVOAvatar constructor and destructor : llinfos << "motions: " << numMotions << llendl;
When avatars are created and destroyed, this value keeps raising.

At the end of a SL client session, it's very easy to get about a value of one thousand LLMotion objects left in memory.

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

catherine pfeffer added a comment - 18/Oct/07 12:58 PM

The LLMotion objects seemed to be released correctly when applying Nicholaz Beresford's patch named "9999_undo_linden_llmotions_from_voice.patch". Marking this issue as duplicate.

There seems to be other memory leaks in LLVOAvatar though. But this jira issue is not the correct place to continue tracking them.

[ Permlink | « Hide ]

catherine pfeffer added a comment - 18/Oct/07 12:59 PM

Closing.

[ Permlink | « Hide ]

catherine pfeffer added a comment - 20/Oct/07 12:59 AM

it's not fixed in 1.18.4 release candidate
there's no issue in Jira to describe it (or I did not find it)

=> unclean situation
=> reopening, removing "duplicate" flag", attaching patch from Nicholaz Beresford.

[ Permlink | « Hide ]

Nicholaz Beresford added a comment - 23/Oct/07 04:23 AM

Note: My patch is merely a reversal of changes in that area (these changes occurred with the first official voice). These changes as in voice also collide with another memory saving patch of mine (~~VWR-1769~~ ... memory bubble)

Soft Linden is aware of the problem.

[ Permlink | « Hide ]

catherine pfeffer added a comment - 31/Dec/08 07:41 AM

Retested with latest client 1.22. The problem is still there, one year later.

[ Permlink | « Hide ]

Ramzi Linden added a comment - 15/Jun/09 03:35 PM

This issue was resolved as "Needs More Info" during a batch clean-up of PJIRA issues.

Reason: for an extended length of time, this bug seems to be missing enough details (reproducible steps) for Linden Lab to import the bug and investigate. Also the last affected version of the viewer on this report is viewer 1.21 or 1.20, 1.19, or even earlier, which are versions that are no longer actively supported.

It is possible that this bug is indeed valid and should remain open-- however, Linden Lab needs the following pieces of information before it is Reopened:

To reopen, please do all of the following:

(1) It is very important to confirm that this bug still occurs in the latest official version 1.23. Please upgrade to that version by browsing to http://get.secondlife.com , and test if you can still reproduce the bug using Viewer 1.23.

(2) If so, then please Reopen this issue and BE SURE to choose the "Affects Version/s" = 1.23

(3) Also, re-describe the steps that another person can follow to experience this bug. An example of a good "recipe" for a bug report can be found here: https://wiki.secondlife.com/wiki/Issue_tracker#Guidelines_for_a_bug_report

(4) Come and attend the inworld bug triages, where you can meet with Linden Lab employees to consider, verify, and expedite bugs for fixing. For more information, see http://wiki.secondlife.com/wiki/Bug_triage

Thank you for helping us improve Second Life!

[ Permlink | « Hide ]

catherine pfeffer added a comment - 20/Jun/09 09:03 AM

If I get some time, I'll recompile a version with the above desribed tests, and prove the problem is still there in 1.23.

If it proves still there (which is very likely to happen), I'll reopen the issue.

Best, – Cathy

[ Permlink | « Hide ]

catherine pfeffer added a comment - 20/Jun/09 03:25 PM - edited

Yes it still happens on 1.23 (as a matter of fact, I have tested it on a self-compiled 1.24.2).

After 84 minutes of wantering around in SL, teleporting very regularily, I noticed 838 LLMotion objects that never got released, for a peak of 1385 LLMotion objects at the worst (in a crowded bar). My memory usage had increased by 683 Mbytes, but that overhead is not necessarily all used for LLMotion objects, as there are probably many other memory leaks. At the end, the test was interrupted because I crashed.

If you never teleport, it is even worse (the LLMotion object count never goes down).

Reopening the issue.