On Oct 31, 2009, at 17:55 , Jean-Denis Muys wrote:
>
> So could it be an obscure bug in connector/C++? Under which
> conditions could client code lead Connector/C++ to write into a
> block it has just freed?
>
I have managed to reduce my memory corruption bug to a single 15-line
routine: the following routine corrupts memory. Remove the "static"
keyword, and no corruption any more:
long execute2(sql::Connection *conn, long condValue)
{
string *q = this->getQueryAsString();
static sql::PreparedStatement* preparedStmt = NULL; // remove static
to prevent memory corruption
if (NULL == preparedStmt)
preparedStmt = conn->prepareStatement(*q);
preparedStmt->setInt(1, condValue);
sql::ResultSet *results = preparedStmt->executeQuery();
long result = 0;
long rowCount = results->rowsCount();
if (rowCount > 0) {
results->first();
result = results->getUInt(1);
}
delete results; // *or* remove this line to prevent memory corruption
return result;
}
Note of course, without the "static", the prepared statement leaks.
That's not the issue here.
The issue is that if the *same* prepared statement is executed twice,
*then* deleting its result set leads it to corrupt memory.
I am really puzzled why.
Any idea?
Jean-Denis
