• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: VWR-85
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Normal Normal
Assignee: Phoenix Linden
Reporter: Strife Onizuka
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR

lsa_cmp_lists, memory leak

Created: 10/Jan/07 01:30 AM   Updated: 24/May/07 05:02 PM
Return to search
Component/s: Scripting
Affects Version/s: None
Fix Version/s: None

File Attachments: 1. File listcompare.diff (2 kB)

Issue Links:
Relates
 

Source Version: 1.13.2.12
Linden Lab Issue ID: SL-33898
Patch attached: Patch attached


 Description  « Hide
\linden\indra\lscript\lscript_library\lscript_alloc.cpp
Lines 1001 -> 1051

There are a few bugs with this function that can be fixed without breaking any existing scripts.
Bug1: Memory Leak: When the lengths are not equal 'list1' & 'list2' are not released before return.
Bug2: Memory Leak: In the while loop, 'list1' & 'list2' are never released before return.
Bug3: 'count' is never incremented so zero is always returned by the while loop.

Incrementing 'count' would break existing scripts. Since the while loop always returns zero, it can be eliminated since zero is the default return at this point.

We can simplify this entire section of code by
Replacing the above mentioned lines with:

delete list1;
delete list2;
return length1 - length2;



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Strife Onizuka added a comment - 10/Jan/07 01:45 AM
I forgot to set the priority, this should be considered Minor and not Major.

Torley Linden added a comment - 11/Jan/07 01:39 PM
Strife, you should be able to change priority via the "Edit this issue" link on the left. =)

Strife Onizuka added a comment - 22/Jan/07 03:58 PM
Attached patch

Strife Onizuka added a comment - 31/Jan/07 08:11 PM
I should have said this sooner, upon review, it doesn't actually leak any memory but what it does do is a very bad programing practice. It deallocated the input lists before working with them, but since the memory isn't overwritten the pointers are still good. It should still work in mono as the GC wouldn't kick in until there were no occurrences left of it. Still doesn't make it a good programing practice. This doesn't seem to be a problem for strings as they seem to have been properly handled in this regard (not sent to GC before needing to be used). The saving grace in LSO is that the memory is in a statically allocated memory block.

It is things like this that make me worry.


Phoenix Linden added a comment - 06/Feb/07 02:16 PM
The dead code was still removed.