[sqlite] Two-line patch to fix memory leak
In sqlite3Fts3Matchinfo():
Near the end of the function, I added two lines:
if( rc!=SQLITE_OK ){
sqlite3_result_error_code(pContext, rc);
}else{
int n = pCsr->nMatchinfo * sizeof(u32);
sqlite3_result_blob(pContext, pCsr->aMatchinfo, n, SQLITE_TRANSIENT);
ADDED:sqlite3_free(pCsr->aMatchinfo);
ADDED: pCsr->aMatchinfo = 0;
}
Notes:
1. I added these two lines while obtaining zero actual understanding of
the internals of sqlite. Like a monkey typing random characters, I
opened vi and hit keys until the leak went away. I have no reason to
believe these lines are correct. All I know is that our test suite
shows some memory leaks unless these two lines are present.
2. I first did this fix back when 3.7.5 was released. And then I
procrastinated about submitting the patch to the mailing list, because I
wanted to wait until I could say something insightful about sqlite
internals, to make me look smarter than the aforementioned monkey.
Anyway, we've got over a year of experience running with "sqlite 3.7.5
plus this patch", and no problems.
3. This week we upgraded to 3.7.11 and the leaks showed up again. So I
reapplied this little patch, and the leaks went away again. And this
time, I have decided not to let my cluelessness prevent me from letting
you folks know about it.
So, FWIW, there it is. :-)
--
E
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Two-line patch to fix memory leak
On 05/11/2012 11:28 PM, Eric Sink wrote:
In sqlite3Fts3Matchinfo():
Near the end of the function, I added two lines:
if( rc!=SQLITE_OK ){
sqlite3_result_error_code(pContext, rc);
}else{
int n = pCsr->nMatchinfo * sizeof(u32);
sqlite3_result_blob(pContext, pCsr->aMatchinfo, n, SQLITE_TRANSIENT);
ADDED: sqlite3_free(pCsr->aMatchinfo);
ADDED: pCsr->aMatchinfo = 0;
}
Thanks for posting this.
Looking at the code, I can't see how the memory leak occurs. Do
you have any idea how to trigger it? Other than this patch, are
you using unmodified 3.7.11 FTS code?
We can't apply the patch as is, even though it is safe (does not
introduce any bugs), because it makes queries that use the 'x'
format specifier with matchinfo() much less efficient.
Dan.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Two-line patch to fix memory leak
Oh darn.
If the leak is not obvious to you, and if my patch would cause an undesirable
side effect, then the leak may somehow be the fault of our code.
I'll have to dig into this a bit further. Sending you our whole tree would be
somewhat less than constructive. Maybe I can narrow down to a small test case.
For now, I can confirm that we have made no other changes to our copy of 3.7.11.
Thanks,
--
E
On May 11, 2012, at 12:50 PM, Dan Kennedy wrote:
> On 05/11/2012 11:28 PM, Eric Sink wrote:
>>
>> In sqlite3Fts3Matchinfo():
>>
>> Near the end of the function, I added two lines:
>>
>> if( rc!=SQLITE_OK ){
>> sqlite3_result_error_code(pContext, rc);
>> }else{
>> int n = pCsr->nMatchinfo * sizeof(u32);
>> sqlite3_result_blob(pContext, pCsr->aMatchinfo, n, SQLITE_TRANSIENT);
>> ADDED: sqlite3_free(pCsr->aMatchinfo);
>> ADDED: pCsr->aMatchinfo = 0;
>> }
>
> Thanks for posting this.
>
> Looking at the code, I can't see how the memory leak occurs. Do
> you have any idea how to trigger it? Other than this patch, are
> you using unmodified 3.7.11 FTS code?
>
> We can't apply the patch as is, even though it is safe (does not
> introduce any bugs), because it makes queries that use the 'x'
> format specifier with matchinfo() much less efficient.
>
> Dan.
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
