Closed Bug 911820 Opened 10 years ago Closed 10 years ago

After I change enable/disable of addon and restart browser, "Restart now" are displayed again and again. So, I cannot change status of addon.


(Toolkit :: Add-ons Manager, defect)

26 Branch
Windows 7
Not set





(Reporter: alice0775, Unassigned)


(Blocks 1 open bug)


(Keywords: regression, Whiteboard: [mozmill])


(2 files, 1 obsolete file)

Build Identifier:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 ID:20130902030220

I notice this problem for approximately one week.
This happens about non-restart-less addons.

Reproducible: intermittent

Steps To Reproduce:
1. Open about:addon
2. Toggle status of addon
3. Click "Restart now" 

4. Observe status of the addon

Actual Results:
Status of the addon is not changed.
"Restart now" are displayed again.

Expected Results:
Status should be changed:
extensions.json.tmp and extensions.json exists after restart browser or exit browser.
I removed extensions.json.tmp and extensions.json and start browser, then the problem was gone.
Blocks: 853388
More reliable STR:

1. Install several non-restart-less addons
2. Restart

3. Open about:addons if necessary
4. Disable one of addon
5. Wait for 30 sec

6. Disable one other of addon
7. Wait for 30 sec
8. Click "Restart now" link

9. Observe "Restart now" link

10. Repeat from step3 if you could not reproduce the problem

Actual Restlts:
 "Restart now" link exists at step 9.
 extensions.json.tmp file exists in profile folder.

Expected Results:
 "Restart now" link should not exist.
 extensions.json.tmp file should not exist in profile folder.
Alice0775, thanks for the steps to reproduce on this, and for the triage on other Addon Manager bugs.

Based on some initial testing, I suspect this is a manifestation of bug 903093. The XPI provider triggers a write of the XPI database at shutdown time when a restart-requiring addon is being disabled, and that write doesn't always complete before the browser shuts down.

I'll start by looking at whether we can avoid doing that write during shutdown. If that doesn't work, we may need to fix bug 903093.
Depends on: 903093
Alice, can you reproduce the bug with the preference "extensions.logging.enabled"=true, and capture the output that Firefox prints to the terminal (standard output)? That would help confirm the cause.
Attached file bugbug0.log
(In reply to :Irving Reid from comment #4)
> Alice, can you reproduce the bug with the preference
> "extensions.logging.enabled"=true, and capture the output that Firefox
> prints to the terminal (standard output)? That would help confirm the cause.

Also, capturing the output with
 "tooolkit.osfile.log" = true
would be useful.
Attached file bugbug1.log (obsolete) —
(In reply to David Rajchenbach Teller [:Yoric] from comment #6)
> Also, capturing the output with
>  "tooolkit.osfile.log" = true
> would be useful.
Attached file bugbug2.log
maybe typo : "tooolkit.osfile.log" = true

Useing: "toolkit.osfile.log" = true
Attachment #800144 - Attachment is obsolete: true
Looking at the logs, it seems that message |writeAtomic| is sent but the function call is never completed. I do not understand what could cause this. If I read correctly |WorkerPrivate::DoRunLoop|, we do not interrupt computations in progress on a worker during shutdown. Unless perhaps js-ctypes is somehow a special case? I seem to remember that js-ctypes does fishy stuff (|AutoCTypesActivityCallback| stuff) that involves callbacks, so it might be that calling C code doesn't count as a computation in progress.

bent, could you shed some light on this?
Flags: needinfo?(bent.mozilla)
Workers are definitely interrupted during shutdown.
Flags: needinfo?(bent.mozilla)
Ok, so I misunderstood the code when I read it.
Is there a way to mark them as uninterruptible?
No, it is not possible to have a worker that cannot be interrupted.

If your worker is doing IO then I think you should be listening to the observer service for 'profile-before-change' so that you can ensure your writes are completed before the profile is torn down. Otherwise once bug 662444 is all finished you'll have this same problem. (I'm surprised that write poisoning didn't catch this.)
Well, if the worker can be interrupted, I suspect that doing stuff before profile-before-change won't be sufficient, will it? We'll just be setting things up for a race condition that will still lose data. Or are you suggesting that we should run the event loop manually until the thread is out of work?
Yes, any IO that must be completed before shutdown has to manually spin the event loop at profile-before-change until that critical IO is completed. Since the user is trying to shut the app down that work should obviously be as minimal/quick as possible.
Bug 888347 may have made this more deterministic.  We now start killing all workers at xpcom-shutdown instead of xpcom-shutdown-threads.
We hit this failure a lot today with our Mozmill tests. Therefore adding our whiteboard flag.
OS: Windows 7 → All
Hardware: x86_64 → All
Whiteboard: [mozmill]
Blocks: 909237
Closed: 10 years ago
OS: All → Windows 7
Hardware: All → x86_64
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.