Possible way to figure out if the previous instance of Chromium crashed?

[Scott Hess]

I'm working on converting browser SQLite usage from regular I/O to mmap.  It uses less memory and should be faster.  One side effect is that where attempting to do regular I/O on a corrupt filesystem returns errors, you can sometimes mmap successfully but then crash trying to access data in the mapped memory (*).

I'm wondering if there's any way to detect that this may have happened, so that on startup the code can do something more thorough before proceeding.  Is anyone out there plugged in to the Chromium state-of-the-art in this area?

Thanks,

scott

(*) This also can happen to any other place we use mmap, of course.  In those cases your Chrome probably stopped working at some release and you re-installed or something.  In this case, Chrome kept working, just one of your databases didn't, until this change.

[Nick Maniscalco]

Scott, would you also want to consider cases where Chrome did not crash, but it did not exit cleanly either?  E.g. the host was powered off or the process was kill -9'd?  I don't know how SQLite works exactly, but I would imagine that when using mmap I/O, kill -9'ing in the middle of an operation may leave the DB in a corrupted (and possibly undetectably corrupted!) state.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Jeremy Roman]

It seems possible, but I don't know if there's guidance about where it should or shouldn't be done.

SessionCrashedInfoBarDelegate shows an infobar when you open from a crashed session (to avoid session-restore/crash loops), using Profile::GetLastSessionExitType.

--

[Scott Hess]

I have no reason to believe that corruption above the filesystem layer would be a problem with mmap.  I'm more concerned about the case where filesytem corruption (I mean like file-not-readable, not file-contains-wrong-stuff) leads to crashes.

[The obvious next question is "What would you do about it?", but one step at a time.  Having a corrupt filesystem probably leads to a host of poor outcomes.]

-scott