memory leak while using function "ExecuteSQL" of class OGRDataSource

[startwithdp]

The "ExecuteSQL" function returns an OGRLayer containing the results of the query,Then I used ReleaseResultSet func to deallocate the OGRLayer memory. And I found that there was memory leaks around the where expression of the SQL statement;

Finally I found there was a bug in the "swq_select_free" function; this function doesn't free the where_expr member of the swq_select struct; The type of where_expr is also a struct--"swq_expr" which needs to be freed by function "swq_expr_free";

I added the followings to the "swq_select_free" function to fix this bug: if( select_info->where_expr!=NULL ) {

swq_expr_free(select_info->where_expr);

}

[Even Rouault]

On which GDAL version have you detected this ? And with which tool did you detect that ?

I don't see any obvious issue by code inspection. Starting with GDAL 1.8, we have the following in swq.cpp :

void swq_select_free( swq_select *select_info )

{
    delete select_info;
}

and in swq_select.cpp :

swq_select::~swq_select()

{
    int i;

    delete where_expr;
    [...]
}

So from the above, the where_expr member should be freed by the destructor of swq_select.

If you see a memory leak, it is perhaps something not directly related to that, in which case you might want to give a way for us to reproduce that easily.

[startwithdp]

First,Thank you for your replying.

I have checked the 1.8.1 version this morning,you are right,it didn't have the bug I had reported yesterday.I think the main point of the solution to solve the memory leak is in the swq_expr_node.cpp file.That is: swq_expr_node::~swq_expr_node() {

CPLFree( string_value );

int i; for( i = 0; i < nSubExprCount; i++ )

delete papoSubExpr[i];

CPLFree( papoSubExpr );

}

Actually ,I detected the bug on version 1.7.x; In this version, the postfix of "swq" file is still ".c" instead of ".cpp". In the swq.c file,"swq_select_free" function indeed forgets to deallocate the "where_expr" memory.

Replying to rouault:

On which GDAL version have you detected this ? And with which tool did you detect that ?

I don't see any obvious issue by code inspection. Starting with GDAL 1.8, we have the following in swq.cpp :

void swq_select_free( swq_select *select_info )

{
    delete select_info;
}

and in swq_select.cpp :

swq_select::~swq_select()

{
    int i;

    delete where_expr;
    [...]
}

So from the above, the where_expr member should be freed by the destructor of swq_select.

If you see a memory leak, it is perhaps something not directly related to that, in which case you might want to give a way for us to reproduce that easily.

[startwithdp]

Sorry,my version is too old...

[Even Rouault]

ok, I'm closing the ticket. To me, it isn't critical enough to deserve a backport in the 1.7 branch that will likely see no newer release...