327907 - Ending process firefox.exe can lead to database corruption

Status: RESOLVED FIXED

(Core :: SQLite and Embedded Database Bindings, defect, P1)

Description

[Ria Klaassen (not reading all bugmail)]

I could reproduce this twice and I'll tell you what happened:

I went to this site: http://www.webwereld.nl/ and there I decided that I wanted to load all links on that site in new windows by means of the bookmarklet "Open all links". But when I saw that it loaded all links really in new windows and not in new tabs like I assumed, I wanted to stop it. So I ended the proces firefox.exe in the task manager. 
Then I wanted to startup firefox again but it did nothing. I found a parent.lock file and deleted it, then I could start it up but everything was empty in Places.
The second time I had no problem with the lock file, I only saw a journal file, it had no problems to startup but also in this case everything was gone.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Attachment: bookmarks_history.sqlite

Empty file

Comment 2

[Brett Wilson]

I think I've seen this also. It probably has something to do with our asynchronous I/O messing up the journaling.

Comment 3

[Brett Wilson]

Tomorrow I will check in new non-alpha versions of sqlite to see if this fixes the problem.

Ria, can you give me any more information about the problem? Does it happen every time? I tested it a lot and I've only seen it once, so I'm having trouble diagnosing the error. Was it using a large fraction of the memory of your system when you killed it?

Comment 4

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #3)
> 
I retried and it happened the second time again. This time there was a tiny bit left in the bookmarks-history file (70 KB). System has a AMD Athlon XP 2000+ processor and 512 MB memory shared with the video. I have made a screenshot of the situation. The screen was white and the bookmarks toolbar looked empty when I ended the process. There were definitely items on it before I clicked the bookmarklet.

Bookmarklet:
javascript:(function(){var n_to_open,dl,dll,i; function linkIsSafe(u) { if (u.substr(0,7)=='mailto:') return false; if (u.substr(0,11)=='javascript:') return false; return true; } n_to_open = 0; dl = document.links; dll = dl.length; for(i = 0; i < dll; ++i) { if (linkIsSafe(dl[i].href)) ++n_to_open; } if (!n_to_open) alert ('no links'); else { if (confirm('Open ' + n_to_open + ' links in new windows?')) for (i = 0; i < dll; ++i) if (linkIsSafe(dl[i].href)) window.open(dl[i].href); } })();

Comment 5

[Ria Klaassen (not reading all bugmail)]

Attachment: screenshot

Comment 6

[Brett Wilson]

Ria, can you check the latest builds? Several hours ago I checked in a bunch of changes to the DB which may affect this, and since I couldn't reproduce this on my system I'm hoping you can tell me if it still breaks. Probably anything after 17:00 pacific time (GMT-8) has it.

Comment 7

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #6)
> 
As soon as there are compiled Places builds available somewhere I'll try it out.

Comment 8

[bomfog]

(In reply to comment #7)
> (In reply to comment #6)
> > 
> As soon as there are compiled Places builds available somewhere I'll try it
> out.

Likewise.  An (less) occasional milestone build would be cool.

Don't know if it's the same problem, but when ff hangs, crashes, loses UI, or otherwise misbehaves such that I have to end the process via task manager, I lose all places (bookmarks (except the defaults) and history).  If I end a *non*malfunctioning ff via taskmanager, all is fine. 

I'll try to figure out what causes the precipitating malfunction when next it happens, for repro'ing purposes.

Has happened with most recent available trunk and branch 3rd-party builds, 02-17 and 02-21, respectively.

Comment 9

[Brett Wilson]

I've tracked this bug down to journal reconstruction. When you terminate the process you get a journal. Most journals work fine. But some of them don't seem to work with our asynchronous I/O module and playing them back corrupts the database. Sending the same journals + DB through the non-asynchronous module works fine.

I'm currently working on figuring this out, but I have a good testcase, so there isn't a need right now for help tracking it down.

Comment 10

[Brett Wilson]

Attachment: A very small patch for a very big bug

Comment 11

[Brett Wilson]

On branch and trunk