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 <[email protected]> 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 > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
