I concur with bob's idea to get a list of open statements. But also like the idea the sqlite3_close_v2 interface that give programmers the option.
Ken Bob Ebert <[EMAIL PROTECTED]> wrote: It seems like a programmer error if a statement remains unfinalized when the DB is closed. It would be great if something about the API would help programmers detect and fix errors like this. Having sqlite3_close return an error helped a little, because it made you aware there was a problem, but it didn't help much in finding the problem. I suspect that if you make sqlite3_close automatically finalize all statements it'll cause more problems for programmers that might still be hanging on to those unfinalized statements. Could you do something in between, where sqlite3_close does close the file and puts all the statements in some kind of "error" state, but which doesn't free all the memory for the unfinalized statements? Then you could safely and reliably report MISUSE later if the statement was accessed. It would also be a nice touch if sqlite3_close could report on the unfinalized statements, even just getting the SQL text used to create the statement would be a huge help in tracking down these leaks. Or add an additional API to report on all unfinalized statements that could be called when this sort of error occurs? --Bob -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of D. Richard Hipp Sent: Tuesday, May 13, 2008 5:22 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Proposed SQLite C/C++ interface behavior change. On May 13, 2008, at 8:02 PM, Scott Hess wrote: > On Tue, May 13, 2008 at 4:51 PM, D. Richard Hipp > wrote: >> The currently documented behavior of sqlite3_close() is that when it >> called on a database connection that has unfinalized prepared >> statements is to return SQLITE_BUSY and fail to close the connection. >> The rational is that we did not want a call to sqlite3_close() to >> destroy sqlite3_stmt* pointers out from under other subsystems. But >> for version 3.6.0 we are considering a behavior change in which a >> call to sqlite3_close() will silently and automatically call >> sqlite3_finalize() on all outstanding prepared statements. >> >> This is, technically, an incompatible change and we strive to avoid >> incompatible changes. But we think it unlikely that this change will >> cause any problems, and in fact we suspect it will likely fix more >> bugs than it will induce. But before we move forward, it seems good >> to submit the idea to the community of SQLite users and programmers. >> >> Does anybody have any thoughts on this proposed behavior changes for >> the sqlite3_close() interface? > > What will happen if you call things like this: > > db = sqlite3_open(...); > sqlite3_prepare_v2(db, zSql, -1, &stmt, NULL); // ... > sqlite3_close(db); > sqlite3_finalize(stmt); > > ??? If sqlite3_finalize() will succeed, then this seems pretty > reasonable to me. If sqlite3_finalize() will fail with a segfault or > somesuch, that may be dangerous. The current behavior in the above is that sqlite3_close() will return SQLITE_BUSY and then the application will leak memory and file descriptors because the database connection is never closed. The proposed new behavior is that the stmt object would be destroyed (and its memory passed to free()) by the sqlite3_close() call. We could arrange for sqlite3_finalize() to attempt to return SQLITE_MISUSE, but if memory were reused in between the close and the finalize, there is a small but non-zero chance that the misuse could go undetected and segfault could result. Or if this were on android and memory used by the stmt object gets unmapped, you might segfault with high probability. > > My rational is that if someone is building a system which is > abstracting SQLite, then it may be that the database handles and the > statement handles will not have clear clean-up ordering (for instance > in a garbage- collected system). One _could_ go ahead and create such > an ordering by using refcounting or whatever is appropriate in your > system, but it would also seem reasonable for SQLite to manage this. > > This may also come up with multi-threaded systems, where it could be > challenging to convince another thread to finalize statements before > calling close. > > I don't suggest that you should be able to do anything interesting > with the orphaned statement handle at this point, other than > finalizing it. I suppose it would be nice if all statement-handle > functions would start throwing SQLITE_MISUSE or other appropriate > error code. > Perhaps a better approach would be to modify sqlite3_close() to return SQLITE_MISUSE if called with unfinalized prepared statements and also fail and assert() in that case. That way, applications would crash during development so that the bugs would be found more quickly, but after delivery (when assert() is usually turned off) would merely leak memory and file descriptors but would otherwise continue functioning. By similar reasoning, perhaps SQLite should always assert(0) in places where it returns SQLITE_MISUSE. This is an abuse of assert() since assert() is only suppose to fail due to internal inconsistencies, not misuse by the caller. But it would get the point across. D. Richard Hipp [EMAIL PROTECTED] _______________________________________________ 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 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users