1632481 - Crash in [@ __pthread_mutex_lock | mozilla::detail::MutexImpl::lock | moz_container_size_allocate]

Status: VERIFIED FIXED

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

Description

[Pascal Chevrel:pascalc]

This bug is for crash report bp-19c793de-a4bf-43f9-97c2-912e80200423.

Top 10 frames of crashing thread:

0 libpthread.so.0 __pthread_mutex_lock /build/glibc-t7JzpG/glibc-2.30/nptl/../nptl/pthread_mutex_lock.c:67
1 firefox-bin mozilla::detail::MutexImpl::lock mozglue/misc/Mutex_posix.cpp:118
2 libxul.so moz_container_size_allocate widget/gtk/mozcontainer.cpp:494
3 libgobject-2.0.so.0 <name omitted> ../../../gobject/gclosure.c:810
4 libgobject-2.0.so.0 signal_emit_unlocked_R ../../../gobject/gsignal.c:3571
5 libgobject-2.0.so.0 g_signal_emit_valist ../../../gobject/gsignal.c:3397
6 libgobject-2.0.so.0 <name omitted> ../../../gobject/gsignal.c:3453
7 libgtk-3.so.0 gtk_widget_size_allocate_with_baseline ./debian/build/deb/gtk/../../../../gtk/gtkwidget.c:6170
8 libgtk-3.so.0 gtk_window_size_allocate ./debian/build/deb/gtk/../../../../gtk/gtkwindow.c:8057
9 libgobject-2.0.so.0 <name omitted> ../../../gobject/gclosure.c:810

I am seeing a spike of these linux crash signature in our last nightly that shipped an hour ago (23 crashes so far).
Changelog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=17aa41e3cb7cdff3b94e26e351e29cc8b9bab18a&tochange=47426d145e246fa1924fbda83a8ecb0d25a6f606

Comment 1

[Pascal Chevrel:pascalc]

Martin, I see 2 GTK patches that landed in the last build (bug 1628583, bug 1632100) could they have caused this crash?

Comment 2

[Pascal Chevrel:pascalc]

90 crashes in the last 2 hours, setting as blocker for 77.

Comment 3

[Sam Sneddon [:gsnedders]]

bisecting this locally points at https://hg.mozilla.org/mozilla-central/rev/4283912e2318f294c400670ceb8fe0af94eab28d

Comment 4

[Pascal Chevrel:pascalc]

Sam, do you have steps to reproduce the crash that allowed you to bisect?

Comment 5

[Sam Sneddon [:gsnedders]]

(In reply to Pascal Chevrel:pascalc from comment #4)

Sam, do you have steps to reproduce the crash that allowed you to bisect?

Literally just ./mach build && ./mach run crashes on startup.

Comment 6

[Pascal Chevrel:pascalc]

David, could your patch in bug 1631941 have caused this regression?

Comment 7

[Sam Sneddon [:gsnedders]]

Note that it still crashes after bug 1631941 re-landed. I'm very confused by the bisect pointing at that rollout, but it does 100% reproducibly start crashing there.

Comment 8

[Darkspirit]

X11 is broken, but native Wayland backend works:

KDE, X11, Debian Testing, Radeon RX480
Startup crash, I can't even start a fresh profile. bp-81174a3d-709a-4e5e-bf5a-262d70200423

bug 1628583 comment 11: mozregression --repo autoland --launch 779722364805 does not exist, so I can't test.

https://hg.mozilla.org/integration/autoland/shortlog/779722364805
mozregression --repo autoland --launch a61ccf5cad2b797e54128af9c2ff3ea1f427065f is fine, commits after this have been backed out, except for 779722364805. I have tested further commits after 779722364805 and I always got "Process exited with code 11".

KDE Wayland:
Firefox works with GDK_BACKEND=wayland ./firefox, it does not work with XWayland.

Comment 9

[Darkspirit]

Please backout bug 1628583 comment 11 and build new Linux Nightlies.

Comment 10

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Fixed by backout of bug 1628583, new Nightlies have been requested.

Comment 11

[Darkspirit]

Verified, fixed by backout.

https://hg.mozilla.org/mozilla-central/shortlog/03626342f6e659ac6699a21e30423e2267c1971f
last bad: mozregression --launch 47426d145e246fa1924fbda83a8ecb0d25a6f606
first good: mozregression --launch 03626342f6e659ac6699a21e30423e2267c1971f