Filipp Andjelo added the comment:
Hi Serhiy,
I tried the short example you gave, but it doesn't crash. I'm getting:
Exception ignored in:
Traceback (most recent call last):
File "./test.py", line 5, in __del__
next(it)
StopIteration
Exception ignored in:
Traceba
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 on
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 "
Filipp Andjelo added the comment:
Ok, the race condition seems not to be the real problem, since the patches
didn't help. Don't want to do any assumptions anymore, but it seems like the
python objects memory is deallocated before the sqlite connection was closed.
The thing is,
Filipp Andjelo added the comment:
Hm, this is strange, because close() can only be called from the same thread
and dealloc() can be called only if reference count is 0, right? So why is
there a mutex again each other anyway? And how can that be, that
sqlite3_close() is called multiple times
New submission from Filipp Andjelo:
Race condition in sqlite close/dealloc crashes the application with double
free(). The pointer is set to NULL outside of mutexed zone, so if close and
dealloc follow each other very shortly application crashes. Please see the
attached patch
