SrsAmf0StrictArray may cause memory leaks.

[alphonsetai]

srs 2.0 (branch of the 2.0 release)

When doing reading comprehension, it was found that SrsAmf0StrictArray may cause memory leaks.

After calling the corresponding copy function and clear function, there may be memory leaks. Since the copy function is a deep copy, while clear function simply calls the clear function of the vector without cleaning up the corresponding memory.

Therefore, it is necessary to maintain a variable for deep and shallow copy within SrsAmf0StrictArray, and perform self-release when calling clear on objects that have been deep copied.

Since my understanding of code reading and comprehension is still in the early stages, I have not yet identified the actual function call path in the code, so it is uncertain whether this memory leak will be triggered.

SrsAmf0Any* SrsAmf0StrictArray::copy()
{
    SrsAmf0StrictArray* copy = new SrsAmf0StrictArray();
    
    std::vector<SrsAmf0Any*>::iterator it;
    for (it = properties.begin(); it != properties.end(); ++it) {
        SrsAmf0Any* any = *it;
        copy->append(any->copy());
    }
    
    copy->_count = _count;
    return copy;
}

void SrsAmf0StrictArray::clear()
{
    properties.clear();
}

TRANS_BY_GPT3

[winlinvip]

The analysis is excellent, and indeed there will be leaks.

The "strict array" uses a vector, while the "object" uses SrsUnSortedHashtable, and its "clear" function is used for releasing.

void SrsUnSortedHashtable::clear()
{
    std::vector<SrsAmf0ObjectPropertyType>::iterator it;
    for (it = properties.begin(); it != properties.end(); ++it) {
        SrsAmf0ObjectPropertyType& elem = *it;
        SrsAmf0Any* any = elem.second;
        srs_freep(any);
    }
    properties.clear();
}

So, the "strict array" is actually neglected, and it should be released.

TRANS_BY_GPT3