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

Status: RESOLVED DUPLICATE of bug 911621

(Toolkit :: Add-ons Manager, defect)

Description

[Alice0775 White]

Build Identifier:
http://hg.mozilla.org/mozilla-central/rev/1179318fb5aa
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:

Comment 1

[Alice0775 White]

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.

Comment 2

[Alice0775 White]

More reliable STR:

1. Install several non-restart-less addons
   Ex. 
   https://addons.mozilla.org/en-US/firefox/addon/dom-inspector-6622/?src=search
   https://addons.mozilla.org/en-US/firefox/addon/scrapbook/
   https://addons.mozilla.org/en-US/firefox/addon/dom-inspector-6622/?src=search
   https://addons.mozilla.org/en-US/firefox/addon/fontinfo/?src=search
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.

Comment 3

[:Irving Reid (No longer working on Firefox)]

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.

Comment 4

[:Irving Reid (No longer working on Firefox)]

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.

Comment 5

[Alice0775 White]

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

bugbug0.log

Comment 6

[David Teller [:Yoric] - still alive but not very active]

Also, capturing the output with
 "tooolkit.osfile.log" = true
would be useful.

Comment 7

[Alice0775 White]

Attachment: bugbug1.log

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

Comment 8

[Alice0775 White]

Attachment: bugbug2.log

maybe typo : "tooolkit.osfile.log" = true

Useing: "toolkit.osfile.log" = true

Comment 9

[David Teller [:Yoric] - still alive but not very active]

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?

Comment 10

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Workers are definitely interrupted during shutdown.

Comment 11

[David Teller [:Yoric] - still alive but not very active]

Ok, so I misunderstood the code when I read it.
Is there a way to mark them as uninterruptible?

Comment 12

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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

Comment 13

[David Teller [:Yoric] - still alive but not very active]

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?

Comment 14

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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.

Comment 15

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Bug 888347 may have made this more deterministic.  We now start killing all workers at xpcom-shutdown instead of xpcom-shutdown-threads.

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+2]]

We hit this failure a lot today with our Mozmill tests. Therefore adding our whiteboard flag.