Open Bug 794160 Opened 12 years ago Updated 2 years ago

Update after restart failed, error said Firefox was still running

Categories

(Toolkit :: General, defect)

Product:
Toolkit
Component:
General
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

Status:
REOPENED

People

(Reporter: jaws, Unassigned)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

Logs
10.76 KB, application/zip
Details
Attached file Logs — 
The "Apply Update" button from the About dialog restarted the browser but then showed a dialog saying that the "Update can't be applied since Firefox is still running."

This appears similar to bug 760027.

I noticed that there was a firefox.exe process that was still running. I'm not sure what can be done to fix this though.

I have attached my c:\programdata\mozilla\logs folder to this bug. I zipped up these logs after it happened.

I don't see any mention of errors in the c:\users\jared\appdata\local\mozilla\firefox\nightly\updates folder. I think those may have been overwritten when the next update got applied. (Offhand, I think we should store the last N update logs in that folder too, similar to the programdata folder).

After killing the still-running Firefox.exe process, I then started the browser and saw a UAC prompt for the update. Both of these issues should be included in the logs.
firefox.exe not exiting has been caused by many different cases that I have seen over the years, is accomplished from app update and other components as a consumer of other code, and is something that app update doesn't control. Also, this is something that app update is unable to log since it is well outside of app update.

Moving over to toolkit -> general though there may be a more appropriate comonent
Component: Application Update → General
Did you by chance have a second session open? Or possibly you had the same browser open with a different profile at the same time?  

Task Manager -> View -> Select Columns -> 
Check on Session ID

Maybe you'd have a second session if you use remote desktop or have a second user on the system.
firefox.exe not exiting is not a problem with either of those dependencies... this has been happening well before those two bugs and has also been a problem for other components such as add-ons manager when it needs to restart as well so removing.
No longer blocks: bgupdates, 481815
Otherwise, ya I think this is a process shutdown problem as per Comment 1.
Ya, I think it can be from either of the 2 things I mentioned in Comment 2 or from what you mentioned in Comment 1.   Most likely what you mentioned in Comment 1.
Then should the following UAC prompt be ignored?
There are cases where we will fallback to the UAC prompt. For example though I doubt this is the case, it might be due to the service being signaled about an update, the service being in a waiting state to update but not being able to continue because firefox.exe doesn't properly exit, and then when you do start it falls back to the UAC method.
This might be caused by a non updater issue, but perhaps there is an updater related error in handling this situation.
rstrong, shouldn't this code be hit and hence return 1 from updater.exe if it was working correctly?
 
#ifdef XP_WIN
  if (pid > 0) {
    HANDLE parent = OpenProcess(SYNCHRONIZE, false, (DWORD) pid);
    // May return NULL if the parent process has already gone away.
    // Otherwise, wait for the parent process to exit before starting the
    // update.
    if (parent) {
      DWORD result = WaitForSingleObject(parent, 5000);
      CloseHandle(parent);
      if (result != WAIT_OBJECT_0)
        return 1;
    }
  }

---------

Jared if you get this error often, could you turn off app.update.staging.enabled and see if it helps?
It wouldn't have gotten to that point because we apply the update after the process exits and restarts. Right?
Note: when I say apply I am not referring to staging and I am referring to the existing files being updated or replaced depending on the code path.
Command line for process ID for staging is -1 so as you said it wouldn't be hit there, but I think for applying the update, we pass <pid>/replace and use the <pid> in that check.

So I think on applying it should wait there for 5 seconds for the process to close.
Agreed but this bug is about the firefox.exe process not exiting so whatever the case the problem is that firefox.exe isn't exiting. We have had this happen for a variety of reasons and it must exit to apply an update. So, I'm not sure what problem with the updater code you are referring to since even if we hit that code in the updater the firefox.exe process hasn't exited and we need it to exit (note that Jared had to kill it in task manager)?
So I agree that the core issue here is in shutdown, or hung process.   And that issue has been around forever-ish.

The part that I think is a bug in updater, and if you want this can be investigated in a sister bug, is that it hits error 36 in the logs.  (Sharing violation).  But it should have not even gotten that far and exited before.
Investigating what is going on for that case in a new bug sounds fine. I wouldn't be surprised if it were due to the state of firefox.exe being a zombie though which would just bring it back to this bug.
Depends on: 794234
Getting more information to see if our expectation matches what happens is being tracked in: Bug 794234.
So next time this happens, it would be good to attach a debugger and load symbols in to check out the threads and callstacks of the hung process.
Sounds good. Thanks for filing bug 794234. I also filed bug 794273 to keep tracking more logs in our appdata\local\mozilla\firefox\nightly\updates folder.
Status: NEW → RESOLVED
Closed: 12 years ago
Depends on: 794273
Resolution: --- → INCOMPLETE
You probably already know this, but this is the page for setting up the symbol server in VS or windbg:
https://developer.mozilla.org/en-US/docs/Using_the_Mozilla_symbol_server
Jared, bug 794234 is for getting more information about when sharing violation happens and bug 794273 is about having additional update logs neither of which cover firefox.exe not exiting and this bug is now resolved -> incomplete. Seems like this bug should stay open to me and I'd like to know why you resolved this bug.
I'm going to re-open this because I have another person from another bug that's having this same issue.


So this log shows that firefox.exe is staying open and is not related to maintenanceservice being scanned for a long time.(In reply to kitchin from comment #38)
> I don't have that path. I do have some "Crash Reports/InstallTime\d+" files
> but I don't have permission to attach file here. The list of the most recent
> ones and their contents:
> 
> firefox-aurora
>   InstallTime20120923030601: 1348447717
>   InstallTime20120923042010: 1348443667
>   InstallTime20120924030626: 1348609054
>   InstallTime20120924042009: 1348564824
>   InstallTime20120925030547: 1348651283
>   InstallTime20120925042009: 1348651231
>   InstallTime20120926042010: 1348677702
> seamonkey-beta
>   InstallTime20120830225246: 1346592378
>   InstallTime20120906034402: 1347336909
>   InstallTime20120912204827: 1348051147
>   InstallTime20120923003628: 1348651879
> 
> I also have one "updates/0/update.log" that I saved before the next
> successful update erased it. Here it is:
> 
> SOURCE DIRECTORY C:\Documents and Settings\(user)\Local Settings\Application
> Data\Mozilla\Firefox\Aurora\updates\0
> DESTINATION DIRECTORY C:\Program Files\Aurora
> NS_main: callback app open attempt 1 failed. File: C:\Program
> Files\Aurora\firefox.exe. Last error: 32
> NS_main: callback app open attempt 2 failed. File: C:\Program
> Files\Aurora\firefox.exe. Last error: 32
> NS_main: callback app open attempt 3 failed. File: C:\Program
> Files\Aurora\firefox.exe. Last error: 32
> NS_main: callback app open attempt 4 failed. File: C:\Program
> Files\Aurora\firefox.exe. Last error: 32
> NS_main: callback app open attempt 5 failed. File: C:\Program
> Files\Aurora\firefox.exe. Last error: 32
> NS_main: callback app open attempt 6 failed. File: C:\Program
> Files\Aurora\firefox.exe. Last error: 32
> NS_main: callback app open attempt 7 failed. File: C:\Program
> Files\Aurora\firefox.exe. Last error: 32
> NS_main: callback app open attempt 8 failed. File: C:\Program
> Files\Aurora\firefox.exe. Last error: 32
> NS_main: callback app open attempt 9 failed. File: C:\Program
> Files\Aurora\firefox.exe. Last error: 32
> NS_main: callback app open attempt 10 failed. File: C:\Program
> Files\Aurora\firefox.exe. Last error: 32
> NS_main: file in use - failed to exclusively open executable file:
> C:\Program Files\Aurora\firefox.exe
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
The other bug is Bug 775458 Comment 38
(In reply to Robert Strong [:rstrong] (do not email) from comment #19)
> I'd like to know why you resolved this bug.

I resolved this bug because it appeared that I didn't have enough information available to find a fix for the issue.
Thanks for the reply. My concern is that the actual issue is difficult to find and there really isn't much the updater can do about the hung process though that seems to be where the bugs usually end up since it prevents updating.
The user can be prompted to restart the computer. I believe that suffices. I get this error roughly 10-20% of the time I update manually. Next time it happens I can verify restarting suffices. It surely does, because unlocking the file works.
Since the firefox.exe process is hung I'm not sure there is a place where we could detect this and prompt the user.
It's already prompting me, "The update could not be installed. Please make sure there are no other copies of Firefox running on your computer, and then restart Firefox to try again." Just add, "If the problem continues, try restarting your computer or device."
You are right and sorry about that... long couple of days. Filed bug 795219
See also Bug 775458 Attachment 713976 [details] for a little more detail on the process locking the file.
(In reply to kitchin from comment #28)
> See also Bug 775458 Attachment 713976 [details] for a little more detail on
> the process locking the file.
That is for plugin-container.exe and this is about firefox.exe... it is a different bug.
It's always the same locking process: System with a very low PID, such as 4.
I've seen the application exe (firefox.exe, seamonkey.exe, thunderbird.exe), as well as plugin-container.exe locked.

Today I saw this one for the first time, for TB (Earlybird):
crashreporter.exe

About a day earlier I was using a TB plugin that crashes. So now I wonder how old those system locks are.

I'm running WinXP on an older processor, with MSE and a PC Tools firewall that likes to check application activity.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: