Closed Bug 1629526 Opened 3 years ago Closed 3 years ago

Crash in [@ MessageLoop::PostTask | mozilla::widget::WaylandDispatchDisplays]

Categories

(Core :: Widget: Gtk, defect, P3)

Unspecified
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla77
Tracking Status
firefox-esr68 --- unaffected
firefox75 --- unaffected
firefox76 --- unaffected
firefox77 --- fixed

People

(Reporter: gsvelto, Assigned: stransky)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Crash Data

Attachments

(2 files)

This bug is for crash report bp-b1ddf323-2ae9-45f2-8339-f21130200412.

Top 10 frames of crashing thread:

0 libxul.so MessageLoop::PostTask ipc/chromium/src/base/message_loop.cc:346
1 libxul.so mozilla::widget::WaylandDispatchDisplays widget/gtk/nsWaylandDisplay.cpp:84
2 libxul.so nsAppShell::ProcessNextNativeEvent widget/gtk/nsAppShell.cpp:277
3 libxul.so <name omitted> widget/nsBaseAppShell.cpp:242
4 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1104
5 libxul.so nsThread::Shutdown xpcom/threads/nsThread.cpp:889
6 libxul.so nsThreadPool::Shutdown xpcom/threads/nsThreadPool.cpp:397
7 libxul.so mozilla::detail::RunnableMethodImpl<nsCOMPtr<nsIThreadPool>, nsresult  xpcom/threads/nsThreadUtils.h:1220
8 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1200
9 libxul.so mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:87

Only two crashes so far but consistent stacks across two different distros so it's probably a valid one.

I wonder what could be null there...

Blocks: wayland
Priority: -- → P3

hm, maybe OOM where NewRunnableFunction() returns nullptr?

I'll try to inspect one of the minidumps tomorrow but I don't think it's an OOM because the machines involved on all three crashes had plenty of free memory. Since we're calling GetDispatcherThreadLoop() twice in a row could this be a race and during the second call mDispatcherThreadLoop is NULL?

Yes, that's possible, thanks.
WaylandDispatchDisplays() uses gWaylandDisplaysMutex to avoid races so let's it also add to ::Shutdown() where mDispatcherThreadLoop is released (https://searchfox.org/mozilla-central/rev/2cd2d511c0d94a34fb7fa3b746f54170ee759e35/widget/gtk/nsWaylandDisplay.cpp#456).

Assignee: nobody → stransky
Pushed by rgurzau@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5e94064c111d
[Wayland] Use mutex when clear mDispatcherThreadLoop, r=jhorak
Pushed by btara@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ddcf3d470581
Fix whitespace lint on nsWaylandDisplay.cpp CLOSED TREE
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77

Hm, the patch here does not fix anything and also causes browser hang on quit on Wayland. Candidate to "the worst patch of year".

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Regressions: 1630172
  • Add gWaylandThreadLoopMutex to guard thread loop shutdown
  • Rename gWaylandDisplaysMutex to gWaylandDisplayArrayMutex to clarify it's mutex for gWaylandDisplays array access
  • Add gWaylandDisplayArrayMutex lock at ReleaseDisplaysAtExit()
  • Rename DispatcherThreadLoop names to ThreadLoop
Pushed by cbrindusan@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1e8f6a6c6f4c
[Wayland] Add gWaylandThreadLoopMutex to guard thread loop shutdown, r=jhorak
Status: REOPENED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → FIXED
See Also: → 1647072
You need to log in before you can comment on or make changes to this bug.