Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v94 crashes gnome-shell when invoking lock screen. #2270

Closed
bennyb0i opened this issue Aug 25, 2024 · 5 comments · Fixed by #2273
Closed

v94 crashes gnome-shell when invoking lock screen. #2270

bennyb0i opened this issue Aug 25, 2024 · 5 comments · Fixed by #2273
Assignees
Labels
needs information Use this tag to identify old issues that can be closed if further information was not provided.

Comments

@bennyb0i
Copy link

After updating to the latest v94, gnome-shell crashes when the lock-screen is invoked, either manually (i.e., Super+L) or by system timer (e.g., set by gnome-control-center). Journal is repeatedly flooded with the following errors:

Aug 25 10:49:08 gnome-shell[1932]: ../glib/gobject/gsignal.c:2685: instance '0x64a82ef43800' has no handler with id '36764'
Aug 25 10:49:08 gnome-shell[1932]: Object .Gjs_ui_appDisplay_FolderView (0x64a82ef43800), has been already disposed — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
    #1   7ffd4de6f200 I   file:///home/user/.local/share/gnome-shell/extensions/[email protected]/utils.js:184 (3e4f5c39a6f0 @ 214)
    #2   7ffd4de6f230 I   file:///home/user/.local/share/gnome-shell/extensions/[email protected]/utils.js:101 (3e4f5c39a380 @ 15)
    #4   7ffd4de6f3e0 b   file:///home/user/.local/share/gnome-shell/extensions/[email protected]/utils.js:101 (3e4f5c39a330 @ 54)
    #5   7ffd4de6f490 b   file:///home/user/.local/share/gnome-shell/extensions/[email protected]/utils.js:56 (3e4f5c39a0b0 @ 15)
    #7   7ffd4de6f5b0 b   file:///home/user/.local/share/gnome-shell/extensions/[email protected]/utils.js:55 (3e4f5c39a060 @ 44)
    #8   64a82cafb428 i   file:///home/user/.local/share/gnome-shell/extensions/[email protected]/appIconsDecorator.js:61 (3e4f5c3b6b00 @ 43)
    #9   64a82cafb3a8 i   file:///home/user/.local/share/gnome-shell/extensions/[email protected]/appIconsDecorator.js:78 (3e4f5c3b6c40 @ 11)
    #10   64a82cafb2e0 i   file:///home/user/.local/share/gnome-shell/extensions/[email protected]/lib/appDisplay.js:781 (3f34a7083ce0 @ 995)
    #11   64a82cafb248 i   file:///home/user/.local/share/gnome-shell/extensions/[email protected]/lib/appDisplay.js:375 (3f34a7083330 @ 17)

OS: Arch Linux x86_64
Kernel: Linux 6.10.6-arch1-1
DE: GNOME 46.4
WM: Mutter (Wayland)
WM Theme: Adwaita

Confirm the issue only arises when dash-to-dock extension is enabled. Tested by disabling all extensions, logging out then in again, and invoking lock-screen without issue.

Tested with only gnome-shell active, logging out then in again, and invoking lock-screen, gnome-shell crashes to login. Can be replicated by doing the same again.

@vanvugt
Copy link
Collaborator

vanvugt commented Aug 26, 2024

Those log messages are not related to shell crashes. Perhaps you mean #2179?

@vanvugt vanvugt added the needs information Use this tag to identify old issues that can be closed if further information was not provided. label Aug 26, 2024
@MorganAntonsson
Copy link
Contributor

I have the same problem. Disabling V-Shell (Vertical Workspaces) fixes it as well. It seems like the latest version (of Dash-to-dock) introduced some conflict between the two. Not sure who is at fault.

@TheRealWolfick
Copy link

I am having the same thing. When my computer went to sleep (goes to the lock screen) gnome-shell completely crashed. Before the crash, my log is filled with the below screenshot.

Screenshot from 2024-08-26 21-44-47

@sergio-costas
Copy link
Collaborator

@3v1n0 Here! Look at the upper capture: aztaskbar is calling something in dash-to-dock...

@3v1n0 3v1n0 self-assigned this Aug 26, 2024
3v1n0 added a commit to 3v1n0/dash-to-dock that referenced this issue Aug 26, 2024
We were removing the container set, but not its children, so let's
cleanup everything when indicators are cleared.

Closes: micheleg#2272, micheleg#2270
3v1n0 added a commit to 3v1n0/dash-to-dock that referenced this issue Aug 26, 2024
If we're tracking an object destruction and that object gets destroyed,
we need to remove the signals handler storage item, or we'd end up
trying to disconnect from it again when destroying the signals handler.

Closes: micheleg#2270
3v1n0 added a commit to 3v1n0/dash-to-dock that referenced this issue Aug 26, 2024
If we're tracking an object destruction and that object gets destroyed,
we need to remove the signals handler storage item, or we'd end up
trying to disconnect from it again when destroying the signals handler.

Closes: micheleg#2270
3v1n0 added a commit to 3v1n0/dash-to-dock that referenced this issue Aug 26, 2024
If we're tracking an object destruction and that object gets destroyed,
we need to remove the signals handler storage item, or we'd end up
trying to disconnect from it again when destroying the signals handler.

Closes: micheleg#2270
@3v1n0 3v1n0 linked a pull request Aug 26, 2024 that will close this issue
@3v1n0
Copy link
Collaborator

3v1n0 commented Aug 26, 2024

It should be fixed by #2273

vanvugt pushed a commit that referenced this issue Aug 27, 2024
We were removing the container set, but not its children, so let's
cleanup everything when indicators are cleared.

Closes: #2272, #2270
vanvugt pushed a commit that referenced this issue Aug 27, 2024
If we're tracking an object destruction and that object gets destroyed,
we need to remove the signals handler storage item, or we'd end up
trying to disconnect from it again when destroying the signals handler.

Closes: #2270
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs information Use this tag to identify old issues that can be closed if further information was not provided.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants