Bug 1837467 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
From inspecting the minidump from [several crashes like this](https://crash-stats.mozilla.org/report/index/1530439d-baeb-47cd-bc27-6989a0230608#tab-details)  with Visual Studio, it seems that we can see situations where we arrived inside the `while (mMainThreadTasks.empty())` (thus having a supposedly empty task queue) and find us stuck on `mMainThreadCV.Wait();`, but looking at `mMainThreadTasks` it seems we **have** some task in the queue, as if there was a race (if we can trust the values in Visual Studio, but they seem reasonable and consistent over some crashes).

```
mMainThreadCV	{...}	mozilla::CondVar mozilla::OffTheBooksCondVar	{mLock=0x000001c923d72060 {...} mImpl={platformData_=0x000001c923d72108 {0x0000000000000000, 0x0000000000000000, ...} } }
mozilla::OffTheBooksCondVar mCurrentTasksMT	{ size=0 }	std::stack<RefPtr<mozilla::Task>,std::deque<RefPtr<mozilla::Task>,std::allocator<RefPtr<mozilla::Task>>>> 
mThreadableTasks	{ size=0 }	std::set<RefPtr<mozilla::Task>,mozilla::Task::PriorityCompare,std::allocator<RefPtr<mozilla::Task>>> 
mMainThreadTasks	{ size=1 }	std::set<RefPtr<mozilla::Task>,mozilla::Task::PriorityCompare,std::allocator<RefPtr<mozilla::Task>>>
```
Revision 1 by
on 
See comment 5 for updated understanding. We came from:

From inspecting the minidump from [several crashes like this](https://crash-stats.mozilla.org/report/index/1530439d-baeb-47cd-bc27-6989a0230608#tab-details)  with Visual Studio, it seems that we can see situations where we arrived inside the `while (mMainThreadTasks.empty())` (thus having a supposedly empty task queue) and find us stuck on `mMainThreadCV.Wait();`, but looking at `mMainThreadTasks` it seems we **have** some task in the queue, as if there was a race (if we can trust the values in Visual Studio, but they seem reasonable and consistent over some crashes).

```
mMainThreadCV	{...}	mozilla::CondVar mozilla::OffTheBooksCondVar	{mLock=0x000001c923d72060 {...} mImpl={platformData_=0x000001c923d72108 {0x0000000000000000, 0x0000000000000000, ...} } }
mozilla::OffTheBooksCondVar mCurrentTasksMT	{ size=0 }	std::stack<RefPtr<mozilla::Task>,std::deque<RefPtr<mozilla::Task>,std::allocator<RefPtr<mozilla::Task>>>> 
mThreadableTasks	{ size=0 }	std::set<RefPtr<mozilla::Task>,mozilla::Task::PriorityCompare,std::allocator<RefPtr<mozilla::Task>>> 
mMainThreadTasks	{ size=1 }	std::set<RefPtr<mozilla::Task>,mozilla::Task::PriorityCompare,std::allocator<RefPtr<mozilla::Task>>>
```
Revision 2 by
on 
See comment 5 of this bug for updated understanding. We came from:

From inspecting the minidump from [several crashes like this](https://crash-stats.mozilla.org/report/index/1530439d-baeb-47cd-bc27-6989a0230608#tab-details)  with Visual Studio, it seems that we can see situations where we arrived inside the `while (mMainThreadTasks.empty())` (thus having a supposedly empty task queue) and find us stuck on `mMainThreadCV.Wait();`, but looking at `mMainThreadTasks` it seems we **have** some task in the queue, as if there was a race (if we can trust the values in Visual Studio, but they seem reasonable and consistent over some crashes).

```
mMainThreadCV	{...}	mozilla::CondVar mozilla::OffTheBooksCondVar	{mLock=0x000001c923d72060 {...} mImpl={platformData_=0x000001c923d72108 {0x0000000000000000, 0x0000000000000000, ...} } }
mozilla::OffTheBooksCondVar mCurrentTasksMT	{ size=0 }	std::stack<RefPtr<mozilla::Task>,std::deque<RefPtr<mozilla::Task>,std::allocator<RefPtr<mozilla::Task>>>> 
mThreadableTasks	{ size=0 }	std::set<RefPtr<mozilla::Task>,mozilla::Task::PriorityCompare,std::allocator<RefPtr<mozilla::Task>>> 
mMainThreadTasks	{ size=1 }	std::set<RefPtr<mozilla::Task>,mozilla::Task::PriorityCompare,std::allocator<RefPtr<mozilla::Task>>>
```
Revision 3 by
on 
Edit: See comment 5 of this bug for updated understanding. We came from:

From inspecting the minidump from [several crashes like this](https://crash-stats.mozilla.org/report/index/1530439d-baeb-47cd-bc27-6989a0230608#tab-details)  with Visual Studio, it seems that we can see situations where we arrived inside the `while (mMainThreadTasks.empty())` (thus having a supposedly empty task queue) and find us stuck on `mMainThreadCV.Wait();`, but looking at `mMainThreadTasks` it seems we **have** some task in the queue, as if there was a race (if we can trust the values in Visual Studio, but they seem reasonable and consistent over some crashes).

```
mMainThreadCV	{...}	mozilla::CondVar mozilla::OffTheBooksCondVar	{mLock=0x000001c923d72060 {...} mImpl={platformData_=0x000001c923d72108 {0x0000000000000000, 0x0000000000000000, ...} } }
mozilla::OffTheBooksCondVar mCurrentTasksMT	{ size=0 }	std::stack<RefPtr<mozilla::Task>,std::deque<RefPtr<mozilla::Task>,std::allocator<RefPtr<mozilla::Task>>>> 
mThreadableTasks	{ size=0 }	std::set<RefPtr<mozilla::Task>,mozilla::Task::PriorityCompare,std::allocator<RefPtr<mozilla::Task>>> 
mMainThreadTasks	{ size=1 }	std::set<RefPtr<mozilla::Task>,mozilla::Task::PriorityCompare,std::allocator<RefPtr<mozilla::Task>>>
```

Back to Bug 1837467 Comment 0