Closed Bug 1684352 Opened 4 years ago Closed 4 years ago

[wayland] Crash when opening links in a new tab

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
86 Branch
Tracking Flags:
Tracking Status
firefox-esr78 --- unaffected
firefox84 --- unaffected
firefox85 --- unaffected
firefox86 + verified

People

(Reporter: emilio, Assigned: emilio)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

Bug 1684352 - Don't assume that there's a vsync dispatcher handy when observing. r=rmader
(deleted), text/x-phabricator-request
Details

https://crash-stats.mozilla.org/report/index/0ceb0f83-77f7-4b8d-a0e1-36d820201228#tab-details

Seems we have a null RefreshTimerVsyncDispatcher, Robert, can you take a look?

Flags: needinfo?(robert.mader)

https://crisal.io/tmp/blank.html reliably reproduces the crash for me.

On a debug build, I can't repro (fun!), but that being said, this:

data:text/html,<a target="_blank" href="data:text/html,Foo">Bar</a>

Does trigger a:

Crash Annotation GraphicsCriticalError: |[0][GFX1-]: We don't have EGLSurface to draw into. Called too early? (t=1.90525) |[1][GFX1-]: We don't have EGLSurface to draw into. Called too early? (t=3.0678) [GFX1-]: We don't have EGLSurface to draw into. Called too early?

and the new tab doesn't properly render.

Component: Layout → Widget: Gtk

Oh ouch, will have a look!

Flags: needinfo?(robert.mader)

I'm poking a bit too, but so far I haven't been able to reproduce on a local build :/

My guess is that if Observe() gets called too early, we can receive the
message before updating the vsync source the first time, which would
trigger this crash.

With this patch, we handle it nicely and UpdateVsyncSource will
re-observe as needed.

It's not 100% clear to me if this is the actually the issue (and thus
whether this patch is the right solution), since I haven't been able to
repro locally, though. There might be a more subtle race.

Assignee: nobody → emilio
Status: NEW → ASSIGNED
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c39107f8d12a
Don't assume that there's a vsync dispatcher handy when observing. r=rmader
Blocks: wr-linux-wayland
Crash Signature: [@ __GI___pthread_mutex_lock ]
status-firefox84: --- → unaffected
status-firefox85: --- → affected
status-firefox86: --- → affected
status-firefox-esr78: --- → unaffected
Keywords: crash, regression
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1680505
Crash Signature: [@ __GI___pthread_mutex_lock ] → [@ __GI___pthread_mutex_lock ] [@ __pthread_mutex_lock | mozilla::detail::MutexImpl::lock | mozilla::RefreshTimerVsyncDispatcher::AddChildRefreshTimer ]

https://hg.mozilla.org/mozilla-central/rev/c39107f8d12a

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
status-firefox86: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch

bug 1681030 comment 22 mentions that Beta 85 was fixed by backout in bug 1645528 comment 71.

status-firefox85: affected → unaffected
Crash Signature: [@ __GI___pthread_mutex_lock ] [@ __pthread_mutex_lock | mozilla::detail::MutexImpl::lock | mozilla::RefreshTimerVsyncDispatcher::AddChildRefreshTimer ] → [@ __GI___pthread_mutex_lock ] [@ __pthread_mutex_lock | mozilla::detail::MutexImpl::lock | mozilla::RefreshTimerVsyncDispatcher::AddChildRefreshTimer ] [@ bp-0ca204d9-cc2a-4210-8af7-b8f900201228]
Crash Signature: [@ __GI___pthread_mutex_lock ] [@ __pthread_mutex_lock | mozilla::detail::MutexImpl::lock | mozilla::RefreshTimerVsyncDispatcher::AddChildRefreshTimer ] [@ bp-0ca204d9-cc2a-4210-8af7-b8f900201228] → [@ __GI___pthread_mutex_lock ] [@ __pthread_mutex_lock | mozilla::detail::MutexImpl::lock | mozilla::RefreshTimerVsyncDispatcher::AddChildRefreshTimer ]
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: