1763727 - Dragging tab window unfortunately still crashes browser

Status: RESOLVED FIXED

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

Description

[Daniel Holbert [:dholbert]]

[tl;dr: I think bug 1761870 is still an issue, but since it had some patches land, let's spin off the remaining part to a new bug so there's not too much going on in one bugzilla page]

STR (same as bug 1761870 comment 5):

1. Start Firefox with fresh profile.
2. Create 3 pinned tabs (and no other tabs else): one tab at https://www.mozilla.org/en-US/privacy/firefox/ and 2 at https://www.example.org/ (exact sites/count probably doesn't matter)
3. Rapidly click and drag the pinned tabs back and forth left to right. (Keep doing this.)

ACTUAL RESULTS:
Within a minute or so of continuous tab-drag-n-dropping, I get a full-browser crash, with this backtrace:

Program $OBJ/dist/bin/firefox (pid = 70734) received signal 11.
Stack:
#01: nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*) ($SRC/toolkit/profile/nsProfileLock.cpp:188)
#02: js::UnixExceptionHandler(int, siginfo_t*, void*) ($SRC/js/src/ds/MemoryProtectionExceptionHandler.cpp:0)
#03: WasmTrapHandler(int, siginfo_t*, void*) ($SRC/js/src/wasm/WasmSignalHandlers.cpp:0)
#04: ??? (/lib/x86_64-linux-gnu/libc.so.6 + 0x42520)
#05: wl_proxy_marshal (/lib/x86_64-linux-gnu/libwayland-client.so.0 + 0x95e9)
#06: mozilla::widget::WindowSurfaceWaylandMB::Commit(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&, mozilla::gfx::IntRegionTyped<mozilla::LayoutDevicePixel> const&) ($SRC/widget/gtk/WindowSurfaceWaylandMultiBuffer.cpp:293)
#07: mozilla::widget::WindowSurfaceWaylandMB::Commit(mozilla::gfx::IntRegionTyped<mozilla::LayoutDevicePixel> const&) ($SRC/widget/gtk/WindowSurfaceWaylandMultiBuffer.cpp:247)
#08: mozilla::widget::WindowSurfaceProvider::EndRemoteDrawingInRegion(mozilla::gfx::DrawTarget*, mozilla::gfx::IntRegionTyped<mozilla::LayoutDevicePixel> const&) ($SRC/widget/gtk/WindowSurfaceProvider.cpp:169)
#09: mozilla::widget::GtkCompositorWidget::EndRemoteDrawingInRegion(mozilla::gfx::DrawTarget*, mozilla::gfx::IntRegionTyped<mozilla::LayoutDevicePixel> const&) ($SRC/widget/gtk/GtkCompositorWidget.cpp:77)
#10: mozilla::wr::RenderCompositorSWGL::CommitMappedBuffer(bool) ($SRC/gfx/webrender_bindings/RenderCompositorSWGL.cpp:240)
#11: mozilla::wr::RenderCompositorSWGL::EndFrame(nsTArray<mozilla::wr::Box2D<int, mozilla::wr::DevicePixel> > const&) ($SRC/gfx/webrender_bindings/RenderCompositorSWGL.cpp:253)
#12: mozilla::wr::RendererOGL::UpdateAndRender(mozilla::Maybe<mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> > const&, mozilla::Maybe<mozilla::wr::ImageFormat> const&, mozilla::Maybe<mozilla::Range<unsigned char> > const&, bool*, mozilla::wr::RendererStats*) ($SRC/gfx/webrender_bindings/RendererOGL.cpp:214)
#13: mozilla::wr::RenderThread::UpdateAndRender(mozilla::wr::WrWindowId, mozilla::layers::BaseTransactionId<mozilla::VsyncIdType> const&, mozilla::TimeStamp const&, bool, mozilla::Maybe<mozilla::gfx::IntSizeTyped<mozilla::gfx::UnknownUnits> > const&, mozilla::Maybe<mozilla::wr::ImageFormat> const&, mozilla::Maybe<mozilla::Range<unsigned char> > const&, bool*) ($SRC/gfx/webrender_bindings/RenderThread.cpp:537)
#14: mozilla::wr::RenderThread::HandleFrameOneDoc(mozilla::wr::WrWindowId, bool) ($SRC/gfx/webrender_bindings/RenderThread.cpp:387)
#15: mozilla::detail::RunnableMethodImpl<mozilla::wr::RenderThread*, void (mozilla::wr::RenderThread::*)(mozilla::wr::WrWindowId, bool), true, (mozilla::RunnableKind)0, mozilla::wr::WrWindowId, bool>::Run() ($OBJ/dist/include/nsThreadUtils.h:1203)
#16: nsThread::ProcessNextEvent(bool, bool*) ($SRC/xpcom/threads/nsThread.cpp:0)
#17: NS_ProcessNextEvent(nsIThread*, bool) ($SRC/xpcom/threads/nsThreadUtils.cpp:465)
#18: mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) ($SRC/ipc/glue/MessagePump.cpp:0)
#19: MessageLoop::RunInternal() ($SRC/ipc/chromium/src/base/message_loop.cc:0)
#20: MessageLoop::Run() ($SRC/ipc/chromium/src/base/message_loop.cc:356)
#21: nsThread::ThreadFunc(void*) ($SRC/xpcom/threads/nsThread.cpp:387)
#22: _pt_root ($SRC/nsprpub/pr/src/pthreads/ptthread.c:204)
#23: set_alt_signal_stack_and_start(PthreadCreateParams*) ($SRC/toolkit/crashreporter/pthread_create_interposer/pthread_create_interposer.cpp:80)
#24: ??? (/lib/x86_64-linux-gnu/libc.so.6 + 0x94947)
#25: clone (/lib/x86_64-linux-gnu/libc.so.6 + 0x124a44)
#26: ??? (???:???)

EXPECTED RESULTS:
No crash.

I captured this crash in rr and uploaded it to pernosco:
https://pernos.co/debug/84FN3goXJyYsc8px_WA9iw/index.html

(Currently MoCo-private by default but I've asked khuey to open it up.)

Comment 1

[Daniel Holbert [:dholbert]]

We're still crashing in wl_proxy_marshal like in bug 1761870, but it's a bit different now.

We're still crashing on this line:

	wl_argument_from_va_list(proxy->object.interface->methods[opcode].signature,
				 args, WL_CLOSURE_MAX_ARGS, ap);

In bug 1761870 comment 14, we were crashing because proxy->object.interface was a null pointer.

In this new case (in my pernosco trace from comment 0 here), proxy->object.interface is non-null! So that's good. But unfortunately proxy->object.interface->methods is null. So when we dereference it to find its [opcode] index, we crash.

Comment 2

[Daniel Holbert [:dholbert]]

(Also, for the record: the local build I used was using https://hg.mozilla.org/mozilla-central/rev/b8732a1c1fa9 [1], which is the merge of the push that included bug 1761870's patches.)

[1] (strictly speaking, I also had one patch locally applied, that I'm reviewing, for unrelated bug 1761870. I rebased that off of tip, i.e. b8732a1c1fa9.)

Comment 3

[Martin Stránský [:stransky] (ni? me)]

Can you please run with MOZ_LOG="WidgetWayland:5" and attach the log here? (from the patched one with a crash).
Thanks.

Comment 4

[Martin Stránský [:stransky] (ni? me)]

One possible fix is to move painting (or just the buffer copy) to main thread as this is a race between rendering and main thread.

Comment 5

[Martin Stránský [:stransky] (ni? me)]

No need to attach the log, I can repro on debug build. Thanks.

Comment 6

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1763727 [Wayland] Paint to Gtk owned wl_surface in main thread r?emilio

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4c01de826e16
[Wayland] Paint to Gtk owned wl_surface in main thread r=emilio

Comment 8

[Sandor Molnar[:smolnar]]

Backed out changeset 4c01de826e16 (bug 1763727) for causing multiple failures in /widget/gtk/<random>

Backout link: https://hg.mozilla.org/integration/autoland/rev/d0a6afbb446428835023de767c08eaadc8dccf53

Push with failures

Failure log bustage

Failure log assertion

Comment 9

[Martin Stránský [:stransky] (ni? me)]

Updated, thanks.
try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ba58bd398f412c51ab2af8650d03c4fe30a7e4ac

Comment 10

[Martin Stránský [:stransky] (ni? me)]

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e9fbb7f017a15867eb165acb9912f545a4180036

Comment 11

[Martin Stránský [:stransky] (ni? me)]

try: https://treeherder.mozilla.org/jobs?repo=try&revision=c4325ac43b1afabc86a12cef820a25bfc59c3520

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/12f655f48fd6
[Wayland] Paint to Gtk owned wl_surface in main thread r=emilio

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: screenshot from a build after the fix

FWIW: I tried to reproduce this in a recent autoland build (after the fix), and I ended up with two superimpmosed pinned-tabs. See in this attached screenshot -- there's an "m" favicon (for my STR's mozilla.org pinned-tab) which has a superimposed "globe" favicon (for my STR's example.org pinned-tab).

Not sure if this is a version of the same underlying issue, vs. something unrelated that I can just get far enough to reproduce now.

Comment 14

[Daniel Holbert [:dholbert]]

Attachment: screencast from a build after the fix

Here's a screencast of me cycling through tabs after ending up in the scenario shown in my just-attached screenshot.

Things do "work"; I can cycle between the superimposed tabs. :) So I wonder if I'm hitting a Firefox frontend tab-strip bug (which is perhaps unrelated to this Wayland bug aside from the fact that the Wayland crash it impossible to reach, at least on Linux-with-Wayland).

Comment 15

[gliu20]

Attachment: Screenshot of two tabs dragged at same time and same back trace

I've also experienced the same thing for normal tabs and the stack trace appears to be the same.

Comment 16

[gliu20]

*similar thing
Sorry I misunderstood they aren't superimposed but appear to be (visually?) in the drag state at same time?

Comment 17

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/12f655f48fd6

Comment 18

[Martin Stránský [:stransky] (ni? me)]

Bug 1739339 may be a variant of the 'double drag' case - we attach one popup to two D&D contexts. I'm looking at it now.