Always call sqlite3_finalize in deallocate func

[haileys]

Prevents memory leak in the case that close is not called before a ResultSet is garbage collected.

close sets c->st to NULL immediately after calling sqlite3_finalize itself, so there is no double-free risk introduced with this change.

[flavorjones]

@haileys Thanks for submitting this PR.

Unfortunately, this is insufficient to prevent memory leaks -- I've added some tests that fail when rake test:valgrind is run (on a Linux system) to demonstrate the problem.

I think this is happening because we can't guarantee that the statement will be finalized before the database is closed. See Closing A Database Connection for more information on what happens when the order is reversed.

[flavorjones]

I've rebased this onto current origin/main.

[tenderlove]

I think this is happening because we can't guarantee that the statement will be finalized before the database is closed. See Closing A Database Connection for more information on wha

I suspect you're not wrong. But I think we might (possibly maybe) be able to do a GC trick that keeps the connection open 1 GC cycle past the statement. AFAIU, the only time we wouldn't be able to guarantee this order is in the case a database object and a statement object are collected at the same time. I think there's a way we can force the connection to stay alive for one more GC. IIRC we do this in CRuby for classes, but idk if the C APIs are public.

[tenderlove]

We might need more tricks in case a db and statement are collected simultaneously, but this is a good start.