GNOME Bugzilla – Bug 735912
History entries are lost if Web is not exited properly
Last modified: 2014-10-03 02:40:47 UTC
Regardless of how long the process is alive, the history entries for a session seem to be lost if I tell GNOME to restart, for instance. The only way to be sure history will be saved for a session seems to be quitting epiphany explicitly. This is probably due to changes to the sqlite database not being committed at any other point than the clean shutdown. Ideally we would commit more often, but just ensuring other ways of shutting down epiphany also save history, such as when the session tells it to quit, would be an improvement.
Does it also affect the session file or only the history database?
(In reply to comment #0) > This is probably due to changes to the sqlite database not being > committed at any other point than the clean shutdown. Ideally we would commit > more often, but just ensuring other ways of shutting down epiphany also save > history, such as when the session tells it to quit, would be an improvement. From reading the code the changes are committed in between commands of the history service, whenever there are changes that schedule a commit, so this shouldn't really be the case. Are you sure that the problem is the epiphany process? It might also be the epiphany search provider rolling back. From reading the code, when the databases are opened there is an unconditional BEGIN TRANSACTION executed that is left open under the assumption that eventually a COMMIT will run. This is only the case when the history service is not in read-only mode. When the service is in read-only mode and the database is closed, sqlite is supposed to rollback, but I don't know if the rollback should affect changes that came from a different process. In any case I think that the unconditional BEGIN TRANSACTION when the databases are opened is wrong.
(In reply to comment #0) > The only way to be > sure history will be saved for a session seems to be quitting epiphany > explicitly. No, this makes no difference for me. Claudio's at least right in that the issue is related to the search provider. Whenever the search provider process is running, my history disappears when I close Epiphany. If it's not running, my history is saved. (In reply to comment #2) > In any case I think that the unconditional BEGIN > TRANSACTION when the databases are opened is wrong. I think we should not open a transaction when the database is in read-only mode, but I think it should be harmless. The transactions are stored as a "journal" on disk, so presumably rolling back a transaction simply rolls back each individual change in the journal.
Created attachment 285875 [details] [review] ephy-history-service: do not open a transaction in read-only mode
Well actually, because the reader has a transaction open, further writes to the database should be blocked until it closes the transaction, so that the reader gets a consistent view of the data. But our reader, the search provider, never releases its transaction. (By the way, it's a problem that the search provider lives forever. They're supposed to quit after a few seconds, 10 usually.) But I'm surprised that doesn't cause our calls to ephy_sqlite_connection_commit_transaction (from ephy_history_service_commit) to return an error code, so maybe that isn't what's happening... I'd expect SQLITE_BUSY, but any error code at all would cause epiphany to crash in ephy_history_service_commit. Relevant: http://www.sqlite.org/lockingv3.html https://www.sqlite.org/atomiccommit.html
Created attachment 285878 [details] [review] search-provider: don't live forever Search providers are supposed to quit after running for a few seconds. I haven't figured out how to test this. If I edit /usr/share/dbus-1/services and replace the Exec line with the path to the search provider in my jhbuild install prefix, it doesn't work at all....
(In reply to comment #5) > But I'm surprised that doesn't cause our calls to > ephy_sqlite_connection_commit_transaction (from ephy_history_service_commit) to > return an error code, so maybe that isn't what's happening... I'd expect > SQLITE_BUSY, but any error code at all would cause epiphany to crash in > ephy_history_service_commit. Indeed, that can't be what's happening: "An attempt to execute COMMIT might also result in an SQLITE_BUSY return code if an another thread or process has a shared lock on the database that prevented the database from being updated. When COMMIT fails in this way, the transaction remains active and the COMMIT can be retried later after the reader has had a chance to clear." https://www.sqlite.org/lang_transaction.html
Comment on attachment 285875 [details] [review] ephy-history-service: do not open a transaction in read-only mode Yes, it's a good idea to not start a transaction in read only mode in any case.
Comment on attachment 285878 [details] [review] search-provider: don't live forever This is probably a different issue, but still, looks good to me.
Attachment 285875 [details] pushed as e7521ae - ephy-history-service: do not open a transaction in read-only mode Attachment 285878 [details] pushed as 2b1d6d6 - search-provider: don't live forever
I think attachment #285875 [details] fixed this. Please reopen if you can still reproduce with the newer search provider.