Oh yeah, I don’t think this is a SQLITE bug or anything. 

I think something in our code is writing to memory after freed. I'm just trying 
to track it down at the point that it happens. We've tried all Profiling tools 
on both OSX and Windows without luck, so my next step is trying to find the 
writing thread at the point of corruption.

Dan Kennedy's suggestion seems like that would we that way to do that.

- Deon

-----Original Message-----
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Simon Slavin
Sent: Wednesday, February 7, 2018 8:32 AM
To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org>
Subject: Re: [sqlite] Header corruption

On 7 Feb 2018, at 3:16pm, Deon Brewis <de...@outlook.com> wrote:

> So this looks more like something is overwriting the memory of Page1 before 
> SQLITE writes it back to disk.

That is almost always what people eventually admit to after reporting a problem 
like this.  Some part of their code is stomping on memory or a file handle 
which SQLite thought it had exclusive rights to.  Some of them discover it 
using a runtime profiler tool which looks for use of released memory or 
double-release of file handles, but I don't know enough about Windows to 
suggest anything.

sqlite-users mailing list
sqlite-users mailing list

Reply via email to