> > Have you examined whether "docker" supports POSIX advisory locks and sync operations correctly? > I must say I haven't. That being said, it seems like SQLite is using docker in the context of OSS-fuzz. SQLite is relying on the filesystem as exposed by the OS API, including its locking, synchronizing and thread-safety, to behave as documented. The library is well tested for a number of implementations of that API, on many platforms. I doubt that Docker's filesystem API, as used by SQLite for its several synchronizing modes, has been tested enough to warrant any faith that it is not subtly different, in a crucial way for the multi-threaded SQLite usage scenario you have outlined. (That is why I suggested keeping SQLite operations to one thread until the database file is created. I might go even further and close the DB connection after that creation and have **all** threads open it the same way.) Of all the "It's not my code's fault!" possibilities, a Docker failing of this kind is early in the descending probability list. > > My money would fall on either the application being in error or "docker" being broken. > Same here, I'm not saying the issue is on sqlite and wouldn't be surprised if the issue was on my end There are some obvious experiments that will distinguish whether Docker is failing your expectation [a] or you have some as-yet-unapparent problem in your code. [a. Your expectation seems to be that SQLite will behave as well on the Docker filesystem as it does on the numerous OS/filesystem combinations it is tested against. I would deem that more of a hope than a reasonable expectation. ]