Freeze at GLContextEGL::GetBufferAge() (eglQuerySurface())
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
People
(Reporter: mystiquewolf, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: crash)
Crash Data
Attachments
(2 files)
Crashes when selecting extensions which have popups AND are located inside the overflow menu.
Maybe Fission related. (DOMFissionEnabled=1)
Crash report: https://crash-stats.mozilla.org/report/index/6de06619-7458-43b6-b431-7ed450220506
MOZ_CRASH Reason: ```Redirecting call to abort() to mozalloc_abort
Top 10 frames of crashing thread:
0 firefox mozalloc_abort /build/firefox/src/firefox-100.0/memory/mozalloc/mozalloc_abort.cpp:35
1 firefox abort /build/firefox/src/firefox-100.0/memory/mozalloc/mozalloc_abort.cpp:88
2 libglib-2.0.so.0 <.text ELF section in libglib-2.0.so.0.7200.1>
3 libglib-2.0.so.0 g_assertion_message_expr
4 libgdk-3.so.0 gdk_wayland_selection_add_targets_libgtk_only
5 libgdk-3.so.0 gdk_window_get_pointer
6 libgtk-3.so.0 gtk_window_reshow_with_initial_size
7 libgobject-2.0.so.0 g_closure_invoke
8 libgobject-2.0.so.0 g_signal_handlers_destroy
9 libgobject-2.0.so.0 g_signal_emit_valist
|
||
Comment 1•4 years ago
|
||
The bug has a crash signature, thus the bug will be considered confirmed.
|
||
Comment 2•4 years ago
|
||
That seems like a GTK crash (we're just redirecting it to mozalloc_abort so that we can get crash reports). Do you know how to reproduce or so?
|
Reporter | |
Comment 3•4 years ago
|
||
Yes.
- Click on
More toolsbutton near theapplication menu. This opens theOverflow menuwith hidden extensions. - From the list of extensions click on some extension that has a
popup. Like uBlock Origin or Fireshot.
|
|
Reporter | |
Updated•4 years ago
|
|
|
Reporter | |
Comment 4•4 years ago
|
||
Emilio, in the gnome bug tracker they want a better stack trace with debug symbols for glib. Arch debuginfod doesn't seem to have symbols for Firefox and maybe your trace server doesn't have debug symbols for glib? Also the crash reports don't appear in coredumpctl. It seems Firefox somehow redirects them to its own crash reporter.
|
|
||
Comment 5•4 years ago
|
||
(In reply to Lyubomir [:mystiquewolf] from comment #4)
Emilio, in the gnome bug tracker they want a better stack trace with debug symbols for glib. Arch debuginfod doesn't seem to have symbols for Firefox and maybe your trace server doesn't have debug symbols for glib?
Huh, Arch doesn't have symbols for Firefox? That's a bit surprising... :heftig do you know what might be going on?
In any case... I'm on Arch right now, and I can't repro this neither in Nightly nor in the arch firefox package...
|
||
Comment 6•4 years ago
|
||
Our debuginfod doesn't have symbols for Firefox because (at least at -g2) they're too much. We only upload the symbols to Mozilla.
|
|
||
Comment 7•4 years ago
|
||
Ok, if the official arch builds are in the mozilla symbol server then I think sourcing this from gdb should do.
|
|
||
Comment 8•4 years ago
|
||
I just tried it with a core dump I had lying around (of bug 1721667) and it does seem to work. However, this dump had no frames outside libxul.so so I don't know if the fetch from our debuginfod still works.
~/.gdbinit:
set debuginfod enabled on
source ~/Downloads/symbols.py
|
|
Reporter | |
Comment 9•4 years ago
|
||
Yes, it worked, i provided the trace in the gnome bug tracker. Thanks!
|
||
Updated•4 years ago
|
|
|
Reporter | |
Comment 10•4 years ago
|
||
Can kinda break Nightly too with this, although there it doesn't crash but it stucks/freezes Firefox.
Can you please create a screencast of the issue?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Collect_information_for_a_bug_report
Thanks.
|
|
Reporter | |
Comment 12•4 years ago
|
||
This is Bug 1771104 and should be fixed in latest Beta/Nightly....can you try so?
|
|
Reporter | |
Comment 14•4 years ago
|
||
This is Bug 1771104 and should be fixed in latest Beta/Nightly....can you try so?
(In reply to Lyubomir [:mystiquewolf] from comment #10)
Can kinda break Nightly too with this, although there it doesn't crash but it stucks/freezes Firefox.
It doesn't crash on nightly like in the above screencast, so maybe it was fixed, but it stucks the UI instead.
Not sure if it's the same underlying reason for doing this. While it was stuck i manually send SISGESV to the firefox (nightly) process with the higher CPU usage and got this stack trace: https://crash-stats.mozilla.org/report/index/cdbdb23e-d101-4794-8ada-ec0b10220607
Mentions something like Mutex there, so might be different.(In reply to Martin Stránský [:stransky] (ni? me) from comment #13)
It doesn't crash on nightly like in the above screencast, so maybe it was fixed, but it stucks the UI instead.
Not sure if it's the same underlying reason for doing this. While it was stuck i manually send SISGESV to the firefox (nightly) process with the higher CPU usage and got this stack trace: https://crash-stats.mozilla.org/report/index/cdbdb23e-d101-4794-8ada-ec0b10220607
Mentions something like Mutex there, so might be different.(In reply to Martin Stránský [:stransky] (ni? me) from comment #13)
Can you try that under mutter if you see the freeze?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_different_Wayland_compositor
Whay you see here is freeze over hidden window where we fails to flush rendering.
Main thread waits in nsWindow::PauseCompositorHiddenWindow() and child is blocked by mozilla::gl::GLContextEGL::GetBufferAge() where it waits to Wayland compositor.
It's possible that the surface is already deleted or so.
|
|
Reporter | |
Comment 16•4 years ago
|
||
FWIW the freeze happens in Nightly in the other bug, this bug is for the crash on Release, which was supposedly fixed.
So for the freeze, i can't make Nightly freeze inside mutter.
|
|
Reporter | |
Comment 17•4 years ago
|
||
Can you try that under mutter if you see the freeze?
Actually not, sorry, my mistake. Yes, what you wrote here is correct
I got the bug with the flickering/flash of Application menu messed up in my head. Nevermind, freeze is the latest incarnation.
So with latest nightly you can reproduce only the freeze and on KDE only, right?
|
|
Reporter | |
Comment 19•4 years ago
|
||
I can reproduce both the application menu moving/flickering on Nightly, and also this bug which is the freeze. Only on KDE. I tried without display scaling on KDE and i can still reproduce. On mutter with 800x600 and no display scaling i cannot reproduce neither.
|
|
||
Comment 20•3 years ago
|
||
Closing because no crashes reported for 12 weeks.
Description
•