Closed Bug 1396110 Opened 7 years ago Closed 7 years ago

Intermittent netwerk/test/unit_ipc/test_redirect_history_wrap.js,test_ext_api_permissions.js | application crashed [@ WatchdogManager::TimeSinceLastActiveContext()]

Categories

(Core :: XPConnect, defect, P5)

defect

Tracking

()

RESOLVED FIXED
mozilla58
Tracking Status
firefox-esr52 --- unaffected
firefox55 --- unaffected
firefox56 --- unaffected
firefox57 --- fixed
firefox58 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: mrbkap)

References

Details

(Keywords: crash, intermittent-failure)

Crash Data

Attachments

(1 file)

This doesn't look like a bug in necko code.
Component: Networking → XPConnect
Summary: Intermittent netwerk/test/unit_ipc/test_redirect_history_wrap.js | application crashed [@ WatchdogManager::TimeSinceLastActiveContext()] → Intermittent netwerk/test/unit_ipc/test_redirect_history_wrap.js,test_ext_api_permissions.js | application crashed [@ WatchdogManager::TimeSinceLastActiveContext()]
This showed up on the day it got added in bug 1376507. Blake, can you take a look at this, please?
Blocks: 1376507
Flags: needinfo?(mrbkap)
Assignee: nobody → mrbkap
Flags: needinfo?(mrbkap)
Can we instead try to re-order things so that UnregisterContext happens after shutting down the watchdog stuff? That seems simpler.
Flags: needinfo?(mrbkap)
That made everything much simpler.
Flags: needinfo?(mrbkap)
Comment on attachment 8910514 [details] Bug 1396110 - Fix races during watchdog shutdown. https://reviewboard.mozilla.org/r/181932/#review188492 ::: js/xpconnect/src/XPCJSContext.cpp:88 (Diff revision 1) > + void forget() > + { > + MOZ_ASSERT(mWatchdog); > + mWatchdog = nullptr; > + } This worries me. It means we could be in the scope of an AutoLockWatchdog without having the lock (if, for example, an inner AutoLockWatchdog took over the lock and then released it). ::: js/xpconnect/src/XPCJSContext.cpp:484 (Diff revision 2) > > // Lock lasts until we return > AutoLockWatchdog lock(self); > > MOZ_ASSERT(self->Initialized()); > MOZ_ASSERT(!self->ShuttingDown()); While you're here, can you please remove this assertion? I don't think it's valid, and it has caused problems for me while testing some stuff. I have a patch to remove it, but I think it's just as easy to fold it in here. As far as I can tell, it's possible for the main thread to quickly start up and then shutdown the watchdog. If that happens, the watchdog thread could start in a state where it's already supposed to shut down.
Attachment #8910514 - Flags: review?(wmccloskey) → review+
Sorry, that first comment was for a previous version of the patch. I don't know why it appeared. Please ignore it.
Pushed by mrbkap@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6e145fde853d Fix races during watchdog shutdown. r=billm
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
Please request Beta approval on this when you get a chance.
Comment on attachment 8910514 [details] Bug 1396110 - Fix races during watchdog shutdown. Approval Request Comment [Feature/Bug causing the regression]: bug 1376507 [User impact if declined]: Possibly shutdown crashes. [Is this code covered by automated tests?]: Yes. [Has the fix been verified in Nightly?]: Not yet (should be soon). [Needs manual test from QE? If yes, steps to reproduce]: No. [List of other uplifts needed for the feature/fix]: n/a [Is the change risky?]: No. [Why is the change risky/not risky?]: This is a pretty simple re-ordering of operations. [String changes made/needed]: n/a
Flags: needinfo?(mrbkap)
Attachment #8910514 - Flags: approval-mozilla-beta?
Comment on attachment 8910514 [details] Bug 1396110 - Fix races during watchdog shutdown. Fix a shutdown issue, taking it. Should be in 57b5
Attachment #8910514 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: