subject:"\[issue26387\] Crash calling sqlite3

[issue26387] Crash calling sqlite3_close with invalid pointer

2021-10-18 Thread Erlend E. Aasland

Erlend E. Aasland added the comment: >From https://sqlite.org/c3ref/close.html: If sqlite3_close_v2() is called with unfinalized prepared statements, unclosed BLOB handlers, and/or unfinished sqlite3_backups, it returns SQLITE_OK regardless, but instead of deallocating the database

[issue26387] Crash calling sqlite3_close with invalid pointer

2021-10-18 Thread Erlend E. Aasland

Erlend E. Aasland added the comment: FYI: We've been using sqlite3_close_v2(), when available, since 2017 (see 86a670543ff97d52fd9b8ca0477f8b6d27ee946d), but we now call it with GIL held. I'm leaning towards closing this as out-of-date. There is no reproducer, there has been no more similar

[issue26387] Crash calling sqlite3_close with invalid pointer

2016-03-09 Thread Filipp Andjelo

Filipp Andjelo added the comment: The issue26494 seems really suspicious, could be our case. And regarding my patch, nice to know, you are the same opinion. However, the code there is looking very strange. I really don't understand, why there are mutex guards anyway, since close() can only be

[issue26387] Crash calling sqlite3_close with invalid pointer

2016-03-08 Thread Serhiy Storchaka

Serhiy Storchaka added the comment: This may be similar to issue26494. As for the patch, _pysqlite_seterror() shouldn't be called when GIL is released. And setting self->db not guarded with GIL looks dangerous. -- ___ Python tracker

[issue26387] Crash calling sqlite3_close with invalid pointer

2016-03-08 Thread Filipp Andjelo

Filipp Andjelo added the comment: Hi Serhiy, unfortunately not, we have one heavy application which is crashing with the given error non deterministically after about 25 hours of running on 40 CPUs with 280GiB memory (!) in use. We already made all kind of test to get it reproducible "in a