Closed Bug 1603854 Opened 2 years ago Closed 2 years ago

Intermittent Windows 10 xpcshell crashes in NS_DispatchToMainThread

Categories

(Core :: Networking, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla73
Tracking Status
firefox73 --- fixed

People

(Reporter: gbrown, Assigned: valentin)

References

Details

(Whiteboard: [necko-triaged])

Crash Data

Attachments

(1 file)

I notice there are a lot of recent xpcshell test failures affecting various tests which involve a crash in NS_DispatchToMainThread.

We seem to be hitting an assertion at

https://searchfox.org/mozilla-central/rev/2f09184ec781a2667feec87499d4b81b32b6c48e/xpcom/threads/nsThreadUtils.cpp#242

  nsCOMPtr<nsIThread> thread;
  nsresult rv = NS_GetMainThread(getter_AddRefs(thread));
  if (NS_WARN_IF(NS_FAILED(rv))) {
    NS_ASSERTION(false,
                 "Failed NS_DispatchToMainThread() in shutdown; leaking");

:froydnj - Any interest or insight?

Flags: needinfo?(nfroyd)

https://bugzilla.mozilla.org/show_bug.cgi?id=1603840 has the clearest assertion stack, which shows that something is going wrong in nsNotifyAddrListener::NotifyObservers, probably dispatching tasks well after shutdown has completed.

https://bugzilla.mozilla.org/show_bug.cgi?id=1601674 has roughly the same stack.

Other bugs have garbage for stacks, but e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1592769 has RtlpHpSegPageRangeShrink in the stack, which bug 1603840 does too. I'm going to venture that all of these would be fixed by making nsNotifyAddrListener not dispatch tasks after xpcom-shutdown-threads or thereabouts.

Flags: needinfo?(nfroyd)

Thanks!

See Also: → 1568571
Component: XPCShell Harness → Networking
Product: Testing → Core
Version: Version 3 → unspecified
Assignee: nobody → valentin.gosu
Priority: -- → P1
Whiteboard: [necko-triaged]
Blocks: 1603764
Pushed by valentin.gosu@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/2c2dc20f2a21
nsNotifyAddrListener: Don't call NS_DispatchToMainThread if mShutdown is true r=froydnj
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla73
No longer blocks: 1601674
Duplicate of this bug: 1601674
No longer blocks: 1601293
Duplicate of this bug: 1601293
No longer blocks: 1592769
Duplicate of this bug: 1592769

Thanks Valentin. Your change appears to have stopped the frequent crashes.

However, I noticed one crash that looks very similar and happened well after your fix landed:

https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=281980567&repo=autoland&lineNumber=2069

I haven't seen any others / not sure if it's worth follow-up...just pointing it out.

Flags: needinfo?(valentin.gosu)

(In reply to Geoff Brown [:gbrown] from comment #11)

Thanks Valentin. Your change appears to have stopped the frequent crashes.

However, I noticed one crash that looks very similar and happened well after your fix landed:

https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=281980567&repo=autoland&lineNumber=2069

I haven't seen any others / not sure if it's worth follow-up...just pointing it out.

patched_BaseThreadInitThunk(int, void*, void*) [WindowsDllBlocklist.cpp:23220e6aef9d9290cb4d1b40d435145f979e962c : 582 + 0x

It looks like the blocklist is creating a thread after shutdown?
I think that's a different bug.

Flags: needinfo?(valentin.gosu)
Crash Signature: [@ NS_DispatchToMainThread(already_AddRefed<nsIRunnable> &&,unsigned int)]

Hi Valentin, is there anything that QA can help with here? And if so, could you provide us with STR? Thanks!

Flags: needinfo?(valentin.gosu)

(In reply to Catalin Sasca, QA [:csasca] from comment #13)

Hi Valentin, is there anything that QA can help with here? And if so, could you provide us with STR? Thanks!

I doubt there's a way to manually reproduce this.

Flags: needinfo?(valentin.gosu)
You need to log in before you can comment on or make changes to this bug.