On Mon, Oct 11, 2010 at 11:15 AM, Roger Binns <[email protected]> wrote:
>
> >> Except: sqlite3_create_collation_v2() does *not* invoke its destructor
> when
> >> it fails. We are thinking that is a bug and are inclined to fix it. Is
> >> changing sqlite3_create_collation_v2() to invoke its destructor when it
> >> fails going to cause problems?
>
> It breaks binary compatibility. However in practise I don't think many
> people actually call the function. I did a Google Code search and found
> zillions of projects having their own copy of sqlite3.{c,h} and sometimes
> the test suite, but very few users of the api,
>
> The most notable is Lua who don't even look at the return code!
> Consequently they would currently leak memory on
> sqlite3_create_collation_v2
> having an error.
>
> In the Android source I did find sqlite3_create_collation_v2 being called
> and it does check the error code, but it too would leak if the destructor
> was not called on failure.
>
> What that means is that fixing this will improve things for all the
> developers who were lax in not even bothering to check return codes, or did
> not have a test suite that caused an error and verified that they cleaned
> up
> properly.
>
> And for those who do check and do clean up properly (so far it looks like
> it
> is just me with that halo :-) ) then fixing this will cause a double free
> and hence program crash when SQLite is dynamically linked.
>
Turns out there is a bug in sqlite3_create_collation_v2() which would cause
it to return SQLITE_OK even if it failed to create a collation due to an OOM
(out-of-memory) error. So apparently even the fastidious Binns-code can fail
to clean up the application data if a malloc failure occurs. Bummer.
Working on a fix now....
--
D. Richard Hipp
[email protected]
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
