Closed
Bug 510017
Opened 15 years ago
Closed 14 years ago
Firefox hangs while trying to rename sessionstore-1.js during AV scan
Categories
(Firefox :: Session Restore, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: elementorange, Unassigned)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729) As a precondition I'd like to state that I have absolutely no control over the AV program installed on my machine (McAfee). Every time Firefox creates a temporary sessionstore-1.js file and immediately tries to rename it to sessionstore.js the AV program locks the file while it's being scanned and Firefox just locks up using 100% of the CPU core the process is running on. The behavior was not present before FF 3.5 and it's really annoying. I've set browser.sessionstore.interval to 6 minutes so I don't have to suffer from the glitch every 10 seconds as the default config would have it. Reproducible: Always Steps to Reproduce: 1. Open Firefox and have McAfee "scan on read/write" activated 2. Make sure the browser.sessionstore.resume_from_crash is set to true and that browser.sessionstore.interval is the default 10 seconds (10000) 3. Browse the Web, open new tabs, scroll down some pages, click some links, etc Actual Results: Every 10 seconds you get a 2 second lock-up while Firefox tries to rename sessionstore-1.js while the AV scans the file Expected Results: Don't have my browser lock-up because it can't rename a temporary file right away. I've read in some forums that sessionstore cant get incredibly big (50Mb and more). I've checked mine and it's only about 150Kb. The workaround is to greatly increase the interval so as to have the problem occur as infrequently as possible or to set browser.sessionstore.resume_from_crash to false and in both cases you can't really expect to "resume from a crash" with your tab intact.
Updated•15 years ago
|
Component: General → Session Restore
QA Contact: general → session.restore
Comment 1•15 years ago
|
||
This should be helped by bug 485976 (since writing the file won't be on the main thread anymore). Maybe an alternative workaround is to have McAfee ignore that file? I don't have McAfee on Windows to test this.
Reporter | ||
Comment 2•15 years ago
|
||
I reported the problem because the corporate rules we have in place at our local branch office the local IT's don't have administrative rights on the AV software and so it's impossible for us to configure McAfee to ingnore the file. Otherwise comment#1 would've indeed been the ideal work around
Reporter, can you try to reproduce this with the latest version of Firefox (3.6)? Please let us know if this is still a problem. Thanks.
Reporter | ||
Comment 4•14 years ago
|
||
My employer has since permitted employees to move to Linux if they choose to and I did, so I no longer have the setup necessary to recreate the conditions for this bug.
Comment 5•14 years ago
|
||
Reopen or file a new bug if you get into a situation you can reproduce.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•