CODEWITHSUNDEEP
c++mysqlmemoryresultset
dan
dan

Reputation: 11

MySQL cpp connector resultset memory leak?

I have an application that sucks up memory when fetching a large resultset (my blob fields can easily run a couple of thousand bytes). After much searching, i think I've tracked the leak to resultset::getblob(). If I comment out the getblob line it runs normally. It's ok if I leave it in the resultset, but once i call getblob I hear that sucking sound that is memory going down the tubes.

Looking at the code for the connector, I see that it returns a "new" istringstream. I think this is the culprit. Where does this "new" get deleted? I do delete the result set, and the preparedstatement. Have also tried closing the resultset to no avail. No examples I see seem to be doing anything to deal with this.

Anyone have any experience with/workaround for this?

TIA!

Upvotes: 1

Views: 755

Answers (2)

Mobile Ben
Mobile Ben

Reputation: 7331

Yep, it seems like we need to release the memory. Here is the code (for mysql_resultset.cpp, there are other files with getBlob that also allocate via new):

/* {{{ MySQL_ResultSet::getBlob() -I- */
std::istream *
MySQL_ResultSet::getBlob(const sql::SQLString& columnLabel) const
{
    CPP_ENTER("MySQL_ResultSet::getBlob(string)");
    /* isBeforeFirst checks for validity */
    if (isBeforeFirstOrAfterLast()) {
        throw sql::InvalidArgumentException("MySQL_ResultSet::getBoolean: can't fetch because not on result set");
    }
    return new std::istringstream(getString(columnLabel));
}
/* }}} */

As there is no internal tracking of this, the caller need to release the memory. One would think that they could have tracked this memory and freed it on destruction, but I suppose they have their reasons.

Upvotes: 1

dingo1220
dingo1220

Reputation: 21

delete the return value of getBlob() function.

or I cause the memory leak.

memory is stable when I delete the instream returned from the getBlob() function.

Upvotes: 1

Related Questions