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

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Daniel Veditz [:dveditz]]

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.

Comment 1

[Robert Strong (they/them - no direct email)]

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.

Comment 2

[[:Cww]]

This isn't just Vista, happening to XP users as well.  Changing the forum to tell users to do a clean install.

Comment 3

[[:Cww]]

http://support.mozilla.com/en-US/forum/1/380950 suggests Zone Alarm is at fault.

Comment 4

[Daniel Veditz [:dveditz]]

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.

Comment 5

[Robert Strong (they/them - no direct email)]

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.

Comment 6

[Robert Strong (they/them - no direct email)]

(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.

Comment 7

[[:Cww]]

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.

Comment 8

[Robert Strong (they/them - no direct email)]

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.

Comment 9

[Robert Strong (they/them - no direct email)]

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.

Comment 10

[Bo]

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.

Comment 11

[anton janssen]

Attachment: last_update.log as requested

last_update.log from my failing update for Firefox 3.5.5 on windows vista home premium.

Comment 12

[anton janssen]

Attachment: update.log as requested

update.log from update/0 dir from my faling ff 3.5.5 update

Comment 13

[anton janssen]

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...

Comment 14

[Matthias Versen [:Matti]]

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

Comment 15

[Robert Strong (they/them - no direct email)]

Anton, from the update.log it appears that Firefox had been launched during the update process. Do you know if this could have happened?

Comment 16

[Robert Strong (they/them - no direct email)]

Attachment: patch in progress

Comment 17

[Alice Wyman]

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

Comment 18

[Robert Strong (they/them - no direct email)]

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?

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

I rarely block to investigate, but this seems like one of those times as it might muck with minor updates.

Comment 20

[Alice Wyman]

(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?

Comment 21

[Robert Strong (they/them - no direct email)]

Attachment: patch in progress rev2

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.

Comment 22

[Robert Strong (they/them - no direct email)]

Attachment: patch in progress rev3 - really close

Verified that this also works with WinCE.

Comment 23

[Robert Strong (they/them - no direct email)]

Attachment: screenshot of OS error message when trying to launch Firefox while an update is being applied

Comment 24

[Robert Strong (they/them - no direct email)]

Attachment: screenshot of update error message when Firefox relaunches

This is the existing write error message which seems appropriate to display when Firefox is in use when trying to apply an update.

Comment 25

[Robert Strong (they/them - no direct email)]

Attachment: patch in progress rev4 - damn near there

Comment 26

[Robert Strong (they/them - no direct email)]

Attachment: Fennec screenshot of update error message when Firefox relaunches

Looks like the OS provided message on WinCE and WinMo isn't as correct / friendly as it is on Windows.

Comment 27

[Robert Strong (they/them - no direct email)]

Attachment: patch rev1

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.

Comment 28

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 29

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/9327ef16ef59

Comment 30

[Robert Strong (they/them - no direct email)]

Pushed to mozilla-1.9.2
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/9556b3bd4f45

Comment 31

[Robert Strong (they/them - no direct email)]

Filed bug 528603 for the issue specific to Zone Labs forceField

Comment 33

[Robert Strong (they/them - no direct email)]

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.

Comment 35

[Robert Strong (they/them - no direct email)]

Another good verification test is to try launching Firefox while an update is being applied.

Comment 36

[Robert Strong (they/them - no direct email)]

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.

Comment 37

[Samuel Sidler (old account; do not CC)]

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.

Comment 38

[Robert Strong (they/them - no direct email)]

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.

Comment 39

[Samuel Sidler (old account; do not CC)]

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. :)

Comment 40

[Robert Strong (they/them - no direct email)]

Attachment: 1.9.1 branch patch in progress

Comment 41

[Robert Strong (they/them - no direct email)]

Attachment: 1.9.1 branch patch in progress

Comment 42

[Robert Strong (they/them - no direct email)]

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.

Comment 43

[Daniel Veditz [:dveditz]]

We haven't been hearing about this problem much lately, we're not going to take this on 1.9.1