Signal 11 in gnome-shell when unlocking

[greatquux]

Describe the bug

A few days ago, gnome-shell started to crash with signal 11 when unlocking the screen. The extension works fine when I don't let the screen lock. The issue continued even after clearing my clipboard history, and only went away when I disabled the extension. My database.log file is 0 bytes now, not sure if there are any other things I can try to reset.

How To Reproduce

Versions

$ gnome-shell --version; echo -n "GCH "; gnome-extensions show [email protected] | grep Version; gsettings --schemadir ~/.local/share/gnome-shell/extensions/[email protected]/schemas list-recursively org.gnome.shell.extensions.clipboard-history


GNOME Shell 47.0
GCH   Version: 45
org.gnome.shell.extensions.clipboard-history cache-only-favorites false
org.gnome.shell.extensions.clipboard-history cache-size 100
org.gnome.shell.extensions.clipboard-history clear-history @as []
org.gnome.shell.extensions.clipboard-history confirm-clear true
org.gnome.shell.extensions.clipboard-history disable-down-arrow true
org.gnome.shell.extensions.clipboard-history display-mode 0
org.gnome.shell.extensions.clipboard-history enable-keybindings true
org.gnome.shell.extensions.clipboard-history history-size 100
org.gnome.shell.extensions.clipboard-history ignore-password-mimes false
org.gnome.shell.extensions.clipboard-history move-item-first true
org.gnome.shell.extensions.clipboard-history next-entry @as []
org.gnome.shell.extensions.clipboard-history notify-on-copy true
org.gnome.shell.extensions.clipboard-history paste-on-selection true
org.gnome.shell.extensions.clipboard-history prev-entry @as []
org.gnome.shell.extensions.clipboard-history private-mode false
org.gnome.shell.extensions.clipboard-history process-primary-selection false
org.gnome.shell.extensions.clipboard-history strip-text false
org.gnome.shell.extensions.clipboard-history toggle-menu ['<Super><Shift>V']
org.gnome.shell.extensions.clipboard-history toggle-private-mode ['<Super><Shift>P']
org.gnome.shell.extensions.clipboard-history topbar-preview-size 10
org.gnome.shell.extensions.clipboard-history window-width-percentage 33

[greatquux]

I included a lot of context lines around the crash - first line is the unlock.
gnome-shell-clipboard-history-crash-log.txt

[hbh7]

Seeing the same thing on two Ubuntu 24.04 machines :(

[SUPERCILEX]

This issue has been going on for years and I've never really understood it. Basically when we try to add a menu item it says the box was deallocated: https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/c3cd21cc166989b3cf20b204e93f7a255b9af58c/js/ui/popupMenu.js#L892. I would file an issue with gnome shell as I don't think this is the extension's fault? But I have no idea.

Error for searchability:

Object St.BoxLayout (0x5ecc1f3e0f60), 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.

[greatquux]

Maybe this has something to do with notifications on the lock screen? Does this extension offer this functionality, and can it be disabled perhaps?

[SUPERCILEX]

By default notifications are disabled so I don't think that's the issue, but you could try deleting notification related code to see if it helps.

[MichalVasut]

This issue is super annoying when it crashes entire gnome shell and closes all apps with the work, but I wonder why it started to appear only in the last week for me, before the weekend it was OK - maybe some update (not really sure of what 🤔)

report - few of these

Oct 30 08:54:59 vasut gnome-shell[63227]: Object St.BoxLayout (0x654e9853d870), 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.
    == Stack trace for context 0x654e9193cb90 ==
    #0   7ffce4eb2bb0 b   resource:///org/gnome/shell/ui/popupMenu.js:768 (4ba816f6880 @ 70)
    #1   7ffce4eb2cb0 b   file:///home/michal/.local/share/gnome-shell/extensions/[email protected]/extension.js:448 (2af5ee0151f0 @ 990)
    #2   7ffce4eb2dd0 b   file:///home/michal/.local/share/gnome-shell/extensions/[email protected]/extension.js:691 (2af5ee015920 @ 149)
    #3   654e91a04268 i   file:///home/michal/.local/share/gnome-shell/extensions/[email protected]/extension.js:279 (67a8a7ecf60 @ 139)
    #4   7ffce4eb38c0 b   file:///home/michal/.local/share/gnome-shell/extensions/[email protected]/store.js:227 (2af5ee016e70 @ 482)
    #5   7ffce4eb3970 b   file:///home/michal/.local/share/gnome-shell/extensions/[email protected]/store.js:236 (2af5ee016e20 @ 98)
    #6   7ffce4eb3a40 b   file:///home/michal/.local/share/gnome-shell/extensions/[email protected]/store.js:143 (2af5ee016c40 @ 210)
    #7   7ffce4eb3ab0 I   file:///home/michal/.local/share/gnome-shell/extensions/[email protected]/store.js:138 (2af5ee016c90 @ 314)
    #8   654e91a041d8 i   resource:///org/gnome/shell/ui/init.js:21 (4ba81670bf0 @ 48)

but before that, there I've noticed some parsing error and TypeError

Oct 30 08:54:59 vasut gnome-shell[63227]: [email protected] Parsing error
Oct 30 08:54:59 vasut gnome-shell[63227]: TypeError: undefined has no properties
    _consumeStream/loop/<@file:///home/michal/.local/share/gnome-shell/extensions/[email protected]/store.js:145:56
    safeParse@file:///home/michal/.local/share/gnome-shell/extensions/[email protected]/store.js:186:9
    parseAvailableAware@file:///home/michal/.local/share/gnome-shell/extensions/[email protected]/store.js:236:16
    loop@file:///home/michal/.local/share/gnome-shell/extensions/[email protected]/store.js:143:26
    _consumeStream/loop/<@file:///home/michal/.local/share/gnome-shell/extensions/[email protected]/store.js:138:11
    @resource:///org/gnome/shell/ui/init.js:21:20

[SUPERCILEX]

Regarding the parsing error, I would need to see the ~/.cache/[email protected]/database.log file.

[MichalVasut]

Regarding the parsing error, I would need to see the ~/.cache/[email protected]/database.log file.

Unfortunatelly there is no such file in that directory, only corrupted.log and I cannot share that (lot of source code from work). What I've noticed, there are contol characters, like in this line

�gjs�gjs --version

which is

U+0001 : <control> START OF HEADING [SOH]
U+0067 : LATIN SMALL LETTER G
U+006A : LATIN SMALL LETTER J
U+0073 : LATIN SMALL LETTER S
U+0001 : <control> START OF HEADING [SOH]
U+0067 : LATIN SMALL LETTER G
U+006A : LATIN SMALL LETTER J
U+0073 : LATIN SMALL LETTER S
U+0020 : SPACE [SP]
U+002D : HYPHEN-MINUS {hyphen, dash; minus sign}
U+002D : HYPHEN-MINUS {hyphen, dash; minus sign}
U+0076 : LATIN SMALL LETTER V
U+0065 : LATIN SMALL LETTER E
U+0072 : LATIN SMALL LETTER R
U+0073 : LATIN SMALL LETTER S
U+0069 : LATIN SMALL LETTER I
U+006F : LATIN SMALL LETTER O
U+006E : LATIN SMALL LETTER N

but that's maybe intentional...

[SUPERCILEX]

Yeah, the corrupted one is what I'd need to see but I totally understand it being sensitive. Non text characters are totally normal, see https://alexsaveau.dev/blog/projects/performance/clipboard/gnome/gch/gnome-clipboard-history#the-compacting-log. If you want to go down the rabbit hole, what I'd do with the file is run it through cargo r -- -v d corrupted.log from the tools dir in this repo to check the metadata for bogus values.