Hi Jens, It would be a good test if you could independently verify my findings using the sample app I wrote to see if you are able to reproduce the corruption with memory mapped I/O turned ON and the fact that there's no corruption when it's turned OFF. I know it seem strange given the documentation you found.
Can I ask what the benefit of having memory mapped I/O is for SQLite? And what are the drawbacks of turning it off? I understand what memory mapped I/O is, reducing the amount of memory needed to load in the data from a file. I use it in other parts of my app such as adding file attachments to an email, but I use the higher level NSDataReadingzMappedAlways option on NSData. NSData *pdfData = [[NSData alloc] initWithContentsOfURL:pdfURL options: NSDataReadingMappedAlways error:nil]; I'm just wondering if I'm going to encounter any other issues by disabling it. Perhaps it needs to be conditionalized for Mac vs. iOS? On Tue, Apr 18, 2017 at 1:42 PM, Jens Alfke <j...@mooseyard.com> wrote: > > > On Apr 18, 2017, at 2:20 AM, Deon Brewis <de...@outlook.com> wrote: > > > > It's not like it was subtle - it's a dead on repro. I was able to repro > this by doing a power cycle 2 hours after shutting the app down. OSX didn't > seem to have any interest in flushing mmap files until you soft reboot the > machine. > > OK, hang on — I just reread the docs on memory-mapped I/O in SQLite. > Memory-mapping is *only used for reads*, never for writes: > > >> When updating the database file, SQLite always makes a copy of the page > content into heap memory before modifying the page. This is necessary for > two reasons. First, changes to the database are not supposed to be visible > to other processes until after the transaction commits and so the changes > must occur in private memory. Second, SQLite uses a read-only memory map to > prevent stray pointers in the application from overwriting and corrupting > the database file. > — https://www.sqlite.org/mmap.html > > Therefore I can’t imagine how using it could trigger database corruption. > It doesn’t affect the way data is written at all! > > I accept that both of you have experimentally seen that memory-mapping > leads to corruption, so I can only assume that either the above > documentation is wrong, or that there’s some subtle bug in SQLite that > alters the way data is written when memory-mapping is enabled. > > —Jens > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
