I have assumed this is an iOS specific issue. This app has been in productions for 3 years now, with the lovely iOS 8.x release - we have started to see this problem. We have a couple thousand users, and it is only with iOS 8.x release that this problem has started to show itself. We filed a bug with Apple, to which they answered 'This is a duplicate of bug XXXXXXX'. And they will not allow us to view status, or progress, or ANYTHING to do with bug XXXXXXX (They are just so wonderful to work with). So we know we are not the only people seeing this.
There is no one particular work flow through our software that exhibits this problem. The only common thing is that when it does occur, it is always during a write operation. Our users use our software all day long and probably perform operations that write to the db thousands of times a day. So it is probably safe to say that 99.999% of the time, we are not seeing this. We are extremely impressed with SQLite and I am pretty much 100% convinced that this is an iOS specific bug. So my question here is - given that this is (most likely) an iOS bug (and getting Apple to do ANYTHING to help us is basically impossible), is there anything I can do on the SQLite side that would minimize chances of corruption? I read that WAL mode is 'better' and have switched to that. But are there any other things I can do to minimize chances of this? Would looking at the db file be helpful in any way? Thanks in advance On Mon, May 4, 2015 at 8:23 AM, Simon Slavin <slavins at bigfraud.org> wrote: > > On 4 May 2015, at 4:09pm, Brandon <brandon at cogent3d.com> wrote: > > > We are using SQLite in an iOS app. We are not using the 'built-in' > SQLite, we are compiling from source. We have been battling an issue where > the database becomes 'malformed'. This occurs when iOS completely crashes > (blue screen, flickering, then restart). It's a pretty hard core crash. As > a result - the db often becomes malformed. My question is - is there > anything I can do to help prevent this? I have enabled 'WAL' mode. At this > point, we are at a loss. I am just not sure what our next step is. > > You've hit a problem with iOS. iOS is a phone OS. It's not designed to > crash, because the rules about phones say that they must always be > available for calling the emergency number, so they mustn't crash. Given > the no-crash rule for real-world performance and released Apps, it doesn't > matter what happens if your App can crash the OS, because if it can crash > the OS Apple will never approve it. > > So a phone OS often does things that computer OS would never do, like > aggressive caching which doesn't bother to update main storage until the > App backgrounds or quits. And this can lead to the type of corruption > you're seeing. And since SQLite is doing everything it can to write to > storage correctly, your fix cannot be done inside something SQLite is doing. > > So your 'treatment' for this problem is not to do with making SQLite more > trustworthy. It's to figure out how you're crashing iOS and stop doing > it. You're going to have to do that sooner or later anyway, because your > App will never get through Apple's approval process for App distribution if > it crashes iOS. > > If you think one of your SQLite calls is causing the crash we can help > you. Do you have any idea what you're calling and under what circumstances > it's happening ? If the thing crashing iOS is not to do with SQLite then > you might be better off asking elsewhere. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- *LEGAL DISCLAIMER:* The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
