408072 - mozstorage crash while loading 20 tabs

Status: VERIFIED WORKSFORME

(Core :: Networking: Cookies, defect, P2)

Description

[Rodrigo]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007121009 Minefield/3.0b2pre ID:2007121009

When there a lot of tabs open and the cpu on 100% after a time it crashes saying 'There was a error writing data to disk. Disk full' This is not the exactly message but it is very close to what I remember.
Error Console says it's a problem with 'mozStorage: error code 14 for database C:\...\cookies.sqlite-journal

Reproducible: Sometimes

Steps to Reproduce:
1.Open more than 20 tabs
2.
3.
Actual Results:  
Error message and Firefox freeze.

Expected Results:  
Load the tabs.

Comment 1

[Rodrigo]

Attachment: Image of error on Error Console

Comment 2

[[e-mail]]

more details from the thread on mozillazine (http://forums.mozillazine.org/viewtopic.php?p=3178832#3178832) where the reporter first mentioned this issue:

I opened the tabs on startup, one after another. Yes it appear while loading (which is bad since a crash deletes my cache). The cpu was 100% all the loading. It wasn't crashing before, but I wasn't opening many tabs, now it crashs consistently. There was one time that as soon ff opened it crashed. No, a particular site don't cause it. I'm on Win XP.

What I noticed is that it only happens when processor goes 100% for a time.
I was using a extension (with check.compability to false) that crashed with this error, after I tried with a clean profile and no extensions and it crashed. 

Comment 3

[[e-mail]]

sounds like it could be related to async writing in the mozstorage code; has anyone seen anything like this? perhaps with the urlclassifier stuff, when it was hanging the browser on trunk (bug 404645)? other services using async could be vulnerable to this, too.

nominating for blocking until we get a handle on this one way or another.

Comment 4

[[e-mail]]

reporter, can you please post a list of the sites you used to demonstrate this? by "reproducible: sometimes", about what percentage of the time do you see the crash (on startup w/ clean profile)?

Comment 5

[Rodrigo]

It crashed when I was using DownThemAll! extension (I had like 2000 files on queue and took a little of cpu time to open) and it crash without this extension (clean profile) when I was on:
www.theinquirer.net
www.tgdaily.com
As those are news site I usually opens all news and let it load while I do something else. It crashed more than once.
About percentage if I don't open many tabs it doesn't crash, but if many tabs it's like 90%.
I will try chkdsk latter but I don't think it's the cause.

Comment 6

[Rodrigo]

Run chkdsk with surface scan. Clean volume. HD is new. The problem is not the HD.

Comment 7

[Shawn Wilsher :sdwilsh]

14 is SQLITE_CANTOPEN for reference.

Comment 8

[[e-mail]]

i'm curious whether there are any sqlite failures reported to cookies. rodrigo, can you enable cookie logging and generate a cookie log for starting the browser and crashing, and then attach it here? instructions can be found at: http://www.mozilla.org/projects/netlib/cookies/cookie-log.html

Comment 9

[Rodrigo]

Sure

Comment 10

[Rodrigo]

Attachment: Cookie log

Comment 11

[[e-mail]]

from the log, looks like we're getting a whole bunch of 0x80520015 failure codes when adding/removing cookies from the db.

0[3355e0]: RemoveCookieFromList(): removing from db gave error 80520015
0[3355e0]: 
0[3355e0]: AddCookieToList(): adding to db gave error 80520015

Comment 12

[Rodrigo]

Attachment: Error dialog

Comment 13

[[e-mail]]

0x80520015 is NS_ERROR_FILE_ACCESS_DENIED, which is the munged code for SQLITE_PERM and SQLITE_CANTOPEN:
http://mxr.mozilla.org/mozilla/source/storage/src/mozStorage.h#65

Comment 14

[[e-mail]]

do you have any virus scanners installed? any other applications or background processes that might open files to read/scan their contents on a regular and frequent basis? if you do, can you disable them and retest? this is one possible cause for sqlite to throw SQLITE_CANTOPEN, when it tries to delete/recreate the journal file and some other process is holding it open...

Comment 15

[Rodrigo]

After killing/stopping most of process the crash didn't happen anymore. 
What is strange is that my antivirus/antispyware are both configured to NOT run in real time. 
I can only suspect of Diskeeper, it defrags the hd automatically but it do only when there are resources available (not the case because firefox use all cpu resources).
There are usually 50 process but with only the basic (20) it run ok.
Anyway I'm packing my pc because I'm moving so I will probably be without access till January.
I guess this bug is invalid, right?

Comment 16

[[e-mail]]

well, firefox is crashing, so this bug definitely isn't invalid. ;)

it'd be nice to narrow down exactly which process is causing this, so we can be more certain of the diagnosis... but for more info on what i described in comment 14, see:
http://www.mail-archive.com/[e-mail]/msg15870.html
http://www.sqlite.org/cvstrac/chngview?cn=3200
and the comments above sqlite3WinOpenExclusive() in sqlite3.c. (this is a windows-only problem; osx and linux have sane file handling.)

i'm not really sure what we can do about this. shawn, maybe we can get drh from sqlite in on this and see what he says? i'd also like to know why once it fails the first time, every single db op after that also fails... that's bad :/

Comment 17

[Shawn Wilsher :sdwilsh]

It fails every time after because that's how our async IO works...

Comment 18

[Damon Sicore (:damons)]

+'ing this and making a P2 as Vlad is concerned there may be dataloss.  Can we confirm?  Please re-prioritize as needed.

Comment 19

[Rodrigo]

Finally moved... Now I have acess but not on my computer, I will try to help anyway. I have Windows Defender and Symantec Enterprise but they are not configured to run real-time. The only thing real-time was Diskeeper, that was defraging my hd automagically. Right now I don´t know what exactly is the problem because when I tested I killed most process possible at once. When my pc arrives I will get down to the process thats causing this crash.

Comment 20

[[e-mail]]

now that bug 408914 is in, this shouldn't crash anymore - but there'll likely still be an underlying problem of some db operations failing. we need to figure out how to handle those in the cookieservice. maybe by keeping around a pending transaction list, and retrying on failure? or just ignore failures, and let the in-memory and on-disk datastores get out of sync.

Comment 21

[Rodrigo]

Been using beta 3 and beta4pre for two days and no crash. This is surely fixed.

Comment 22

[Shawn Wilsher :sdwilsh]

without a specific fix, this is WORKSFORME.  And please don't VERIFY your own bugs.

Comment 23

[Rodrigo]

ok

Comment 24

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

(It's perfectly appropriate for the reporter to VERIFY a fix -- that's often the best way to ensure that the original report is actually addressed, and not just a likely analogue of it.)