Closed Bug 1603153 Opened 4 years ago Closed 4 years ago

Crash in [@ PR_GetThreadID | mozilla::UntrustedModulesProcessor::Enqueue]

Categories

(Core :: XPCOM, defect)

73 Branch
All
Windows
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla73
Tracking Status
firefox-esr68 --- unaffected
firefox71 --- unaffected
firefox72 --- unaffected
firefox73 --- fixed

People

(Reporter: philipp, Assigned: karlt)

References

(Regression)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

This bug is for crash report bp-90a964e0-25ba-474f-8a25-4193a0191211.

Top 10 frames of crashing thread:

0 nss3.dll PR_GetThreadID nsprpub/pr/src/threads/prcthr.c:138
1 xul.dll void mozilla::UntrustedModulesProcessor::Enqueue toolkit/xre/UntrustedModulesProcessor.cpp:257
2 xul.dll void mozilla::DllServices::NotifyDllLoad toolkit/xre/WinDllServices.cpp:115
3 xul.dll nsresult mozilla::detail::RunnableMethodImpl<RefPtr<mozilla::AudioTrackEncoder>, void  xpcom/threads/nsThreadUtils.h:1176
4 xul.dll mozilla::SchedulerGroup::Runnable::Run xpcom/threads/SchedulerGroup.cpp:295
5 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1256
6 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:486
7 xul.dll nsThread::Shutdown xpcom/threads/nsThread.cpp:928
8 xul.dll mozilla::LazyIdleThread::ShutdownThread xpcom/threads/LazyIdleThread.cpp:275
9 xul.dll nsresult mozilla::LazyIdleThread::Notify xpcom/threads/LazyIdleThread.cpp:538

this crash signature is starting to appear in 73.0a1 since build 20191210095443.
the pushlog/buglist for this build:
*https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=86afe431ec55&tochange=06d011234636
*https://mzl.la/2rq1ziF

out of these changes, perhaps it's bug 1599922 triggering this?

Flags: needinfo?(karlt)

Yes, this is a regression from https://hg.mozilla.org/mozilla-central/rev/3f0b4e206853, thanks. That change permitted nsThread::GetPRThread() to return null.

The nsThread is accessed on the same thread on which it is shutdown, which is the main thread that created the LazyIdleThread, and the LazyIdleThread clears its nsThread reference on the same thread immediately after nsThread::Shutdown() and so there is no race with the deletion of the PRThread.

LazyIdleThread::GetPRThread() has the convention of throwing an exception (as well as returning null) when there is no PRThread, which seems consistent with nsIThread documentation that says nothing of the PRThread attribute potentially having a null value. UntrustedModulesProcessor() handles the exception and does not expect a null PRThread on successful GetPRThread().

Assignee: nobody → karlt
Status: NEW → ASSIGNED
Component: General → XPCOM
Flags: needinfo?(karlt)

as is done in LazyIdleThread::GetPRThread().

Please feel free to land the patch, if it is reviewed, while I'm away.

Regressed by: 1599922
Pushed by ktomlinson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/31f72cc99309
throw an exception from nsThread::GetPRThread() when there is no PRThread r=froydnj
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla73
Crash Signature: [@ PR_GetThreadID | mozilla::UntrustedModulesProcessor::Enqueue] → [@ PR_GetThreadID | mozilla::UntrustedModulesProcessor::Enqueue] [@ PR_GetThreadID | mozilla::BackgroundPriorityRegion::Clear]
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: