Closed Bug 525390 Opened 10 years ago Closed 10 years ago

Prevent starting Firefox while updating - 3.5.4 Upgrade failure: "entry point js_SaveRegExpStatics could not be located"

Categories

(Toolkit :: Application Update, defect)

x86
Windows Vista
defect
Not set

Tracking

()

RESOLVED FIXED
Tracking Status
status1.9.2 --- beta3-fixed
blocking1.9.1 --- -
status1.9.1 --- wontfix

People

(Reporter: dveditz, Assigned: rstrong)

References

Details

(Keywords: common-issue+)

Attachments

(7 files, 5 obsolete files)

105.12 KB, text/plain
Details
82.42 KB, text/plain
Details
34.11 KB, image/png
Details
21.81 KB, image/png
Details
70.96 KB, image/png
Details
18.67 KB, patch
vlad
: review+
Details | Diff | Splinter Review
15.85 KB, patch
Details | Diff | Splinter Review
Many people reported that after the attempted update to Firefox 3.5.4 they got the message "The procedure entry point js_SaveRegExpStatics could not be located in the dynamic link library js3250.dll"

During 3.5.4 development bug 500644 renamed internal function js_SaveRegExpStatics to js_SaveAndClearRegExpStatics. It's exported because XPConnect needs to call it (from firefox.exe) but it's really an internal function and there should be no external callers.

Forum members report that in addition to js3250.dll they also have a js3250.dll.bak in their install dir, and that copying the .bak file over the .dll results in a working browser. Since Firefox does not then complain about a missing js_SaveAndClearRegExpStatics I'm guessing they still had the old firefox.exe and therefore the update failed in the middle (also bolstered by the presence of the .bak file which should have gotten deleted).

I can think of a few things that might have locked up the firefox.exe so we couldn't replace it, but I thought the updater was designed to recover from that kind of thing. There may be a bug in that recovery process.

https://support.mozilla.com/en-US/forum/1/484861

The suggestion on that forum to go with the .bak file means the users likely have none or few of the 3.5.4 security fixes.
blocking1.9.1: --- → ?
status1.9.1: --- → ?
note: the file is js3250.dll.moz-backup.

Sounds like it might be a failure with a file in use and it would help to get a last-update.log from an affected system to figure out which file is in use. Whatever the case, it should have restored all of the files and reported an error. Also, none of the reports I have read stated that an update error was reported which *might* point to the update succeeding and something else happening.
This isn't just Vista, happening to XP users as well.  Changing the forum to tell users to do a clean install.
Keywords: common-issue+
Summary: 3.5.4 Upgrade failure on Vista, "entry point js_SaveRegExpStatics could not be located" → 3.5.4 Upgrade failure: "entry point js_SaveRegExpStatics could not be located"
http://support.mozilla.com/en-US/forum/1/380950 suggests Zone Alarm is at fault.
Blocks: 525492
1.9.2 probably needs a fix for this, too. It won't have this exact symptoms (and the next 3.5.x upgrade won't either) but we can't be generating frankenbuilds from failed updates.
blocking1.9.1: ? → needed
Flags: blocking1.9.2?
With the current info the only thing I can think of that would cause this is the disk being full though I highly doubt that is the cause or some other app (anti-virus software?) preventing the file from being updated. I just tried to reproduce with a file in use and the correct error was displayed and the files were correctly restored.
(In reply to comment #3)
> http://support.mozilla.com/en-US/forum/1/380950 suggests Zone Alarm is at
> fault.
Saw that as well and though it is for a different error it could very well be the cause. It would be great if we could find out if this could be confirmed somehow.
https://support.mozilla.com/en-US/kb/Entry+point+js_SaveRegExpStatics+could+not+be+located is up now thanks to zzxc.  Hopefully that will help users.
I went ahead and purchase Zone Alarm Extreme to see if I am able to reproduce.Removing regression keyword since this appears to be a new problem and no changes to the update code have been identified as causing this.
Keywords: regression
It would be extremely helpful if we could get a copy of the last-update.log, backup-update.log, and / or the update.log (this one resides in the updates/0 dir) from an affected system.
I installed ZoneAlarm Extreme Security on a fresh XP Virtual Machine with Firefox 3.5.3 and could not reproduce.

As Administrator: I tried enabling virtualization in ZAES (ZAES Window > Browser security > Settings button > Advanced panel > Enable virtualization) and using Firefox for a bit. Then I updated to FF3.5.4 without issue.

I installed FF3.5.3 again and, removed ZAES's Firefox references (ZAES Window > Program Control) and tried again without virtualization. Still no issue.

I repeated the above as a limited user. I wasn't able to update - I got silent failures, a software license agreement missing error (this might be a bug involving dead code in Firefox), and prompts to login as Admin, but no js3250.dll error.

I was also not able able to reproduce by making the Firefox updater programs "restricted" in the ZAES window or by removing permissions to js3250.dll (though if you remove everything, you can't run Firefox at all).

The forum thread in comment 3 strongly suggests ZAES is at fault in a related error. I suspect that maybe the poster in that thread had a previous malware infection (e.g. http://kb.mozillazine.org/This_application_has_failed_to_start_because_js3250.dll_was_not_found - this file has been targeted by malware before) that ZAES was blocking for a different reason. I'm not sure how ZAES does its quarantine, but this seems feasible.
last_update.log from my failing update for Firefox 3.5.5 on windows vista home premium.
update.log from update/0 dir from my faling ff 3.5.5 update
Additional information to comment #11 and #12:
I was updating FF from v3.5.2 to v3.5.5, while at the same time updating windows vista using microsoft update. Maybe this was interfering? Note that I do not have ZAES (or any other product from Zonelabs) installed...
I don't know if it's related :
We got a few reports in the past about a mismatch between the Gecko and Firefox version caused by ZA Forecefield, an example would be 505961
Anton, from the update.log it appears that Firefox had been launched during the update process. Do you know if this could have happened?
Attached patch patch in progress (obsolete) — Splinter Review
Assignee: nobody → robert.bugzilla
Status: NEW → ASSIGNED
Related thread in the ZoneAlarm forum:
http://forums.zonealarm.com/showthread.php?t=71698
WARNING: Firefox 3.5.5 Update can break ForceField: a patch is in the works
Alice, it isn't clear from that thread that this is the same bug. Can you provide any confirmation that it is in that the error "entry point js_SaveRegExpStatics could not be located" is displayed on launching Firefox?
I rarely block to investigate, but this seems like one of those times as it might muck with minor updates.
Flags: blocking1.9.2? → blocking1.9.2+
(In reply to comment #18)
> Alice, it isn't clear from that thread that this is the same bug. Can you
> provide any confirmation that it is in that the error "entry point
> js_SaveRegExpStatics could not be located" is displayed on launching Firefox?

Not in that thread but that specific error is mentioned in another ZA ForceField forum thread, in the November 3, 2009 post by chrislay:
http://forums.zonealarm.com/showthread.php?t=71155
Firefox won't load?
Attached patch patch in progress rev2 (obsolete) — Splinter Review
From several of the reports using zonelabs it appears that disabling it fixes Firefox. I'll take a look at whether I can reproduce and come up with a solution but in the meantime anton's logs looks like Firefox was relaunch while an update was taking place which this patch addresses.
Attachment #411318 - Attachment is obsolete: true
Verified that this also works with WinCE.
Attachment #411640 - Attachment is obsolete: true
This is the existing write error message which seems appropriate to display when Firefox is in use when trying to apply an update.
Looks like the OS provided message on WinCE and WinMo isn't as correct / friendly as it is on Windows.
Attached patch patch rev1Splinter Review
Benjamin, the fix for this is essentially the same as bug 312010. I've tested it quite thoroughly and believe it is good to go and it doesn't cause Bug 354772.
Attachment #411914 - Attachment is obsolete: true
Attachment #412167 - Flags: review?(benjamin)
Attachment #412167 - Flags: review?(benjamin) → review?(vladimir)
Comment on attachment 412167 [details] [diff] [review]
patch rev1

This looks fine to me -- most of the patch is unrelated (log fixes and stuff), and the checking looks straightforward.

One comment I'd have is that a lot of effort goes into doing the right cleanup at error conditions; wonder if it'd be better to put all that state into a stack-allocated class with a destructor that knows how to do the right thing?  Might prevent some odd cases from happening in the future.
Pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/9327ef16ef59
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Filed bug 528603 for the issue specific to Zone Labs forceField
One way to verify this is:
1. Launch the app with a specific profile and no remote (e.g. -no-remote -P profilename
2. Launch the app again with a different profile.
3. check for updates and apply the update available.

You should not get the software update dialog with the progress bar and you should ger the alert stating that the update could not be applied due to file's in use, etc.

btw: I verified this and a couple other scenarios with today's partial update.
Another good verification test is to try launching Firefox while an update is being applied.
drivers, to get this for 1.9.1 would require a decent amount of work to port the code. Re-nominating for 1.9.1 since I want to verify that the patch is still wanted in light of bug 528603 and that a fairly large patch to the updater will be accepted.
blocking1.9.1: needed → ?
A bug with "blocking1.9.1 needed" means we want to block on it when a patch is ready. If your patch is ready for 1.9.1, let's take it in the next cycle.
blocking1.9.1: ? → .7+
Hey Sam, you and I talked about the other day about this bug. It will require some significant changes to the updater and YOU asked me to renominate. I'll go ahead and create the patch based on what has landed on 1.9.2 with the expectation that it will be accepted.
Yeah, sorry Rob. I didn't realize this bug was already marked as "needed" only that it was marked as "wanted". Work up a patch because we want it. :)
blocking1.9.1: .8+ → needed
I highly suspect that the patch in this bug only handles much more rare case where the update fails miserably and that the typical case for this bug is due to ZoneAlarm's Forcefield which is bug 540764. We've contacted Checkpoint to try to figure out how either they or ourselves can fix that issue... the problem is in my understanding that Forefield make Firefox work within a virtual file system and everything that gets written to the file system can be removed which leaves Firefox in a frankenfox state.

Also, the changes required to the updater to land this patch on 1.9.1 are significantly different than what was landed on 1.9.2 due to adding unicode path support for Windows which makes me uncomfortable landing this patch on 1.9.1... I would actually be more comfortable porting back all of the changes so there is consistency between the 1.9.1 and 1.9.2 code since the 1.9.2 code has been in the wild and hence tested by a greater number of users.
We haven't been hearing about this problem much lately, we're not going to take this on 1.9.1
blocking1.9.1: needed → -
Summary: 3.5.4 Upgrade failure: "entry point js_SaveRegExpStatics could not be located" → Prevent starting Firefox while updating - 3.5.4 Upgrade failure: "entry point js_SaveRegExpStatics could not be located"
You need to log in before you can comment on or make changes to this bug.