Bug #360 Severe memory leak in MySQL++ Result copy operator

Submitted: 2 May 2003 13:52 Modified: 3 May 2003 9:00
Reporter: Jeremy Linton Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL++ Severity:S1 (Critical)
Version:1.7.9 OS:Linux (Linux)
Assigned to: CPU Architecture:Any

[2 May 2003 13:52] Jeremy Linton
Description:
There is a bad memory leak in the MySQL++ Result copy operator. It is irritated when an empty result set is assigned to a non empty result set.

How to repeat:
code like the following

Result list_of_volumes;
while (1)
{
  query << "LOCK TABLES Volumes Read";
  list_of_volumes = query.store();
  query << "select * from Volumes";
  list_of_volumes = query.store();
}

Suggested fix:
reverse the purge() and blank result check code in ResUse::copy(const ResUse& other)

Initial code:
void ResUse::copy(const ResUse& other) {
  if (!other.mysql_res) {
     mysql_res=0; _types=0; _names=0; return;
  }
  if (initialized)
    purge();
.....

Change to 

void ResUse::copy(const ResUse &other)
{
   //maybe check for this==other...?
   //
   // clear the current copy...
   if (initialized) {
     purge();
   }
   //blank result set?
   if (!other.mysql_res) {
      mysql_res=0; 
      _types=0; 
      _names=0; 
      return;
   }
[3 May 2003 9:00] MySQL Verification Team
SQLQuery::operator<< 

was not designed to handle commands like "LOCK TABLES".

But, still this patch will be applied in a little bit modified format.

Thank you.

Temporary Workaround:

use Connection::exec() method to run commands like "LOCK TABLES"

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.038 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.