Description of problem: During initial setup, I clicked on google online account that become gray, then the window suddenly close. Version-Release number of selected component: gnome-initial-setup-3.33.92-2.fc31 Additional info: reporter: libreport-2.10.1 backtrace_rating: 4 cgroup: 0::/user.slice/user-1000.slice/user/gnome-initial-setup-first-login.service cmdline: /usr/libexec/gnome-initial-setup --existing-user crash_function: webkitWebViewBaseMakeGLContextCurrent executable: /usr/libexec/gnome-initial-setup journald_cursor: s=9c6104750fa6472098099be7cb122db8;i=15d6;b=794d4a3fbe0845c09418d01128b6a297;m=17845232;t=5921d5126c563;x=4fc1181b28bcfea4 kernel: 5.3.0-0.rc6.git0.1.fc31.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 webkitWebViewBaseMakeGLContextCurrent at /usr/include/c++/9/bits/unique_ptr.h:357 #1 WebKit::WebPageProxy::makeGLContextCurrent at ../Source/WebKit/UIProcess/gtk/WebPageProxyGtk.cpp:161 #2 WebKit::WaylandCompositor::Surface::setWebPage at ../Source/WebKit/UIProcess/gtk/WaylandCompositor.cpp:176 #3 WebKit::WaylandCompositor::unregisterWebPage at ../Source/WebKit/UIProcess/gtk/WaylandCompositor.cpp:574 #4 WebKit::AcceleratedBackingStoreWayland::~AcceleratedBackingStoreWayland at ../Source/WebKit/UIProcess/gtk/AcceleratedBackingStoreWayland.cpp:144 #6 std::default_delete<WebKit::AcceleratedBackingStore>::operator() at /usr/include/c++/9/bits/unique_ptr.h:75 #7 std::unique_ptr<WebKit::AcceleratedBackingStore, std::default_delete<WebKit::AcceleratedBackingStore> >::reset at /usr/include/c++/9/bits/unique_ptr.h:399 #8 std::unique_ptr<WebKit::AcceleratedBackingStore, std::default_delete<WebKit::AcceleratedBackingStore> >::operator=(decltype(nullptr)) at /usr/include/c++/9/bits/unique_ptr.h:333 #9 webkitWebViewBaseDispose at ../Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp:553 #11 gtk_overlay_forall at gtkoverlay.c:628
Created attachment 1613109 [details] File: backtrace
Created attachment 1613110 [details] File: core_backtrace
Created attachment 1613111 [details] File: cpuinfo
Created attachment 1613112 [details] File: dso_list
Created attachment 1613113 [details] File: environ
Created attachment 1613114 [details] File: exploitable
Created attachment 1613115 [details] File: limits
Created attachment 1613116 [details] File: maps
Created attachment 1613117 [details] File: mountinfo
Created attachment 1613118 [details] File: open_fds
Created attachment 1613119 [details] File: proc_pid_status
This is strange. In a VM it works. On baremetal I encounter this issue. Each time that on initial setup I try to set up a google account, the window where I should put my credentials become gray. If I close such window, initial setup crashes. Note: the same thing happens as well on gnome-control-center. So the problem could not be related to gnome-initial-setup.
Similar problem has been detected: Gnome-initial-setup crashes when Google or Microsoft account dialog is opened. The window is completely blank, and once you try to close it, the whole g-i-s crashes and you only have an empty screen (you can still reboot the system from the upper right corner, then g-i-s runs again). This only happens on bare metal or a VM with 3D acceleration (gnome-boxes by default, virt-manager if you enable it), on a VM without 3d acceleration everything works fine. reporter: libreport-2.10.1 backtrace_rating: 4 cgroup: 0::/user.slice/user-978.slice/session-c1.scope cmdline: /usr/libexec/gnome-initial-setup crash_function: webkitWebViewBaseMakeGLContextCurrent executable: /usr/libexec/gnome-initial-setup journald_cursor: s=5c6d42f88c404a37a58100e69c21be27;i=56f;b=3ce8ade1b07048e38c089ca8d43b45d5;m=2377175;t=5926ebe9988a8;x=f96107d10e412eb3 kernel: 5.3.0-0.rc6.git0.1.fc31.x86_64 package: gnome-initial-setup-3.34.0-2.fc31 reason: gnome-initial-setup killed by SIGSEGV rootdir: / runlevel: N 5 type: CCpp uid: 978
Created attachment 1614865 [details] video bug demonstration
I can confirm this also happens when adding Online Accounts in Settings. I propose this as F31 Final blocker, due to following criteria: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use. " https://fedoraproject.org/wiki/Fedora_31_Final_Release_Criteria#Default_panel_functionality "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system." https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_installed_system_boot_behavior You can't add certain accounts (Google, Microsoft, perhaps more) in online accounts on systems with 3D hardware acceleration (bare metal, boxes, virt-manager with 3D acceleration enabled). The gnome-initial-setup crashes if you try to do so and fails to create a user account (of course, you can reboot and avoid the crashing dialog, that works fine).
(In reply to Kamil Páral from comment #15) > You can't add certain accounts (Google, Microsoft, perhaps more) in online So 3D acceleration is the reason why on a KVM machine I didn't spotted the issue, while I can't create online accounts on baremetal as reported on comment 12, right?
(In reply to Alessio from comment #16) > So 3D acceleration is the reason why on a KVM machine I didn't spotted the > issue, while I can't create online accounts on baremetal as reported on > comment 12, right? Very likely. If you use virt-manager, configure your VM to use virtio video (3d acceleration enabled) and spice display (OpenGL enabled, Listen Type: None) and you should see the crashes even in your VM. That's how I reported this (and also verified the bare metal crashes yesterday). Or use gnome-boxes with default options and it should behave the same way.
(In reply to Kamil Páral from comment #17) > Very likely. If you use virt-manager, configure your VM to use virtio video > (3d acceleration enabled) and spice display (OpenGL enabled, Listen Type: I can confirm that. Enabling 3D Acceleration it crashes. Otherwise, with 3D acceleration disable, it works.
See also bug 1749709 Is that a duplicate of this one? Or vice versa :-)
*** Bug 1749709 has been marked as a duplicate of this bug. ***
BTW I think you should report a second bug for the view not rendering. This bug will be resolved when the crash is fixed, but that's not going to do anything to make it display stuff.
(In reply to Michael Catanzaro from comment #21) > BTW I think you should report a second bug for the view not rendering. This > bug will be resolved when the crash is fixed, but that's not going to do > anything to make it display stuff. Good idea, already reported as bug 1751936.
(In reply to Kamil Páral from comment #22) > Good idea, already reported as bug 1751936. Also: bug #1748817.
Discussed during the 2019-09-16 blocker review meeting: [0] The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criterion: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-09-16/f31-blocker-review.2019-09-16-16.02.txt
There is a fix to this bug already - https://trac.webkit.org/changeset/249947/webkit. The other issue - bug 1751936 is probably caused by mesa - at least according to https://bugs.webkit.org/show_bug.cgi?id=200856#c18
FEDORA-2019-fef2eda60a has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-fef2eda60a
webkit2gtk3-2.26.0-2.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-fef2eda60a
The update works here. Thanks.
webkit2gtk3-2.26.0-2.fc31 fixes the issue.
webkit2gtk3-2.26.0-2.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.