On Fri, Apr 6, 2012 at 1:54 PM, Jim Ursetto <[email protected]> wrote:
> I believe there is a bug when deleting or modifying an existing function > with nArg == -1, when there is also an existing function of the same name > with nArg >= 0. It occurs because when nArg == -1, the match quality is > always 6 for the first function encountered regardless of arity, assuming > encoding is equal. When later trying to modify or delete the nArg == -1 > function, create_function may find the existing nArg >= 0 function as best > match, instead of the existing nArg == -1 function. This causes a new > function to be created and the existing nArg == -1 function is never > deleted--leaked, effectively, until the database is closed. As a side > effect, existing prepared statements are not expired in this case, so they > continue to point to the old function. > > Slightly more concrete example: > > Create a function foo with 1 argument, encoding UTF8 > Create a function foo with -1 arguments, encoding UTF8 > - sqlite3FuncDefInsert splices the new function foo after the > existing function foo in the bucket linked list > Delete or modify foo with -1 arguments, encoding UTF8 > - findFunction finds foo with 1 argument (as it was added first) > - matchQuality returns score 6 (exact match) for foo with 1 argument, > because nArg == -1 > - foo with 1 argument is selected as best match > - However, nArg != pBest->nArg, so a new function is created > - And the old function is not destroyed until the database is closed. > - Existing statements are not expired and continue to refer to the old > function. > I followed your recipe above, and step three works correctly for me. The varargs version of the app-defined function is replace/deleted and the single argument version continues to operate as it did before. Can you perhaps send a specific test case - code that we can compile that demonstrates your problem? > > This basically arises from a difference in the desired meaning of "exact > match" during function lookup and creation. Reversing the order in which > the > best match is done--e.g. changing the > to >= in the if(score>bestScore) > loop > test--just changes the order in which the functions need to be defined to > trigger the bug. > > Unfortunately I can't come up with a fix at the moment. > > Jim > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
