Vitals causing Gnome to crash fully and make it unresponsive, when logged in (after both power and suspend)

[xandemon]

Has this issue been covered in the Wiki?

• I have read the Wiki and my issue is not covered.

Is there an existing issue reported already?

• I have searched the existing issues, it does not exist.

What is the unexpected behavior?

Same as #447 . I'm surprised this issue was closed without even trying to understand the issue because I've been facing this exact issue for quite some time. I always have to make sure to disable vitals before turning off my system because if not, it'll crash gnome as soon as i power it on again and won't be able to use my machine at all.

And I'm sure that Vitals is causing the crash because I tried with no other extensions enabled but just Vitals and the issue was there and not when vitals was disabled. I think there's something to do with vitals accessing gnome system info before they are properly initialized?? I can share logs if any moderator/contributor is actually interested to look into it unlike last time.

Steps to reproduce the unexpected behavior.

Check old issue

Relevant log output

gnome-shell[3989]: Object St.Label (0x5626cfcaa2d0), has been already disposed —
impossible to set any property on it.

What distribution and version of Linux are you using?

Fedora 43

What version of Gnome are you using?

49

[azadevlab]

@xandemon hi, please could you share more details?

1. does it happen every time after sleep ?

2. after extension (vitsals) will be crashed once again - get the logs

journalctl /usr/bin/gnome-shell --since "5 minutes ago" | grep -i "vitals"

3. could you post all your extensions?

gnome-extensions list
gnome-extensions list --enabled
gnome-extensions list --active

4. temporary disable other extensions and leave just vitals, test sleep and suspend, if no errors then could you enable by one extension at once, so we can detect conflicted extension

gnome-extensions list --active | grep -iv vitals | xargs -n 1 gnome-extensions disable

[xandemon]

@azadevlab yes, almost every time or quite often actually.
Already tried 3, and 4 and confirmed it to be vitals.

Summarized from logs, here's the exact sequence:

18:26:08 — System begins shutting down (or restarting GDM)
18:26:10 — The Vitals extension (Vitals@CoreCoding.com) tries to update its sensor display widgets, but they've already been destroyed as GNOME Shell is tearing down
This floods the GJS runtime with "object already disposed" errors for hundreds of St.Label objects
18:26:14 — GNOME Shell hits an unrecoverable state and receives SIGABRT (signal 6), crashing hard
The crash happens during session teardown/restart, which is exactly the window when you resume from lock or suspend — GNOME Shell briefly restarts

The Vitals extension has a cleanup/teardown bug where it doesn't properly cancel its sensor polling timers before the UI objects are destroyed.

[azadevlab]

cool (I mean thanks for quick feedback😅)
please could you temporary fix it , test and post results - is it still crash?

1. change in sensors at line 1065

nvim +1065 ~/.local/share/gnome-shell/extensions/Vitals@CoreCoding.com/sensors.js 

from

    destroy() {
        this._destroyFrameMonitor();
        this._terminateNvidiaSmiProcess();

        for (let signal of Object.values(this._settingChangedSignals))
            this._settings.disconnect(signal);
    }

to

    destroy() {
        // TODO: temp fix https://github.com/corecoding/Vitals/issues/542
        this._sleepDestroyed = true;

        this._destroyFrameMonitor();
        this._terminateNvidiaSmiProcess();

        for (let signal of Object.values(this._settingChangedSignals))
            this._settings.disconnect(signal);
    }

line 773
from

    _returnValue(callback, label, value, type, format) {
        // don't return if value is not a number - will revisit later
        //if (isNaN(value)) return;
        callback(label, value, type, format);
    }

    _discoverHardwareMonitors(callback) {

to

    _returnValue(callback, label, value, type, format) {
        // don't return if value is not a number - will revisit later
        //if (isNaN(value)) return;
        // callback(label, value, type, format);

        // TODO: temp fix https://github.com/corecoding/Vitals/issues/542
        if (this._sleepDestroyed) return;
        if (callback) callback(label, value, type, format);
    }

    _discoverHardwareMonitors(callback) {

2. change in extension.js at line 376

nvim +398 ~/.local/share/gnome-shell/extensions/Vitals@CoreCoding.com/extension.js 

from

    _updateDisplay(label, value, type, key) {
        // update sensor value in menubar
        if (this._hotLabels[key]) {
            this._hotLabels[key].set_text(value);

to

    _updateDisplay(label, value, type, key) {
        // TODO: temp fix https://github.com/corecoding/Vitals/issues/542
        if (!this._sensors || this._sensors._destroyed) return;

        // update sensor value in menubar
        if (this._hotLabels[key]) {
            this._hotLabels[key].set_text(value);

and line 376 (nvim +376 ~/.local/share/gnome-shell/extensions/Vitals@CoreCoding.com/extension.js)

from

    _destroyTimer() {
        // invalidate and reinitialize timer
        if (this._refreshTimeoutId != null) {
            GLib.Source.remove(this._refreshTimeoutId);
            this._refreshTimeoutId = null;
        }
    }

to

    _destroyTimer() {
        // // invalidate and reinitialize timer
        // if (this._refreshTimeoutId != null) {
        //     GLib.Source.remove(this._refreshTimeoutId);
        //     this._refreshTimeoutId = null;

        // TODO: temp fix https://github.com/corecoding/Vitals/issues/542
        if (this._monitorTimeoutId) {
            GLib.source_remove(this._monitorTimeoutId);
            this._monitorTimeoutId = null;
        }
    }

[corecoding]

Thanks @azadevlab. #447 was closed because no supporting logs were provided. The logs that were in the ticket were from someone else, not related to the crash (See Wiki regarding "...").

I am personally not seeing this issue. I definitely think you should try the code changes above. What is your "seconds between updates" set to?

[azadevlab]

@xandemon honestly Chris is right
I had Gnome 48, 49 and now 50 on my CachyOS with 1 second interval and haven't any issues

just to be clear, do you have NVIDIA card and nvidia-suspend and nvidia-sleep (or something similar should be) services activated?

and could you just leave CPU (Sensors -> Monitor processor) and check sleep - is it still crashing?

[xandemon]

sorry guys, got busy with life past few days. I'll try above things and let you know real soon. Thanks!

[xandemon]

Hi @azadevlab @corecoding , I implemented local fix you guys mentioned and tested. No problems so far. All good if it works. I'll leave this issue open a little longer just in case and manually close it afterwards. Just wondering if we should merge this fix to the main extension release as well??

And for my sensors, here is it:

btw, it's not NVIDIA. Mine is Intel Core Ultra 5 125H processor with its integrated Arc graphics if that's helpful.

Thanks!