Tails

#2 Updated by intrigeri 2019-06-11 09:27:56

sajolida says resuming from suspend works fine on a X201.

#4 Updated by intrigeri 2019-06-17 14:10:38

On resume (both in 190608-alienpup-hp-pavilion-dm4-buster-sudo-journalctl.out and 190608-alienpup-lenovo-tp-t410-buster-sudo-journalctl.out), I see that our torstatus GNOME Shell extension makes GNOME Shell segfault:

Jun 09 00:15:26 amnesia systemd[1]: Stopped target Tor has bootstrapped.
Jun 09 00:15:26 amnesia systemd[1]: Stopping Manage the flag file that indicates whether Tor has bootstrapped...
Jun 09 00:15:26 amnesia nm-dispatcher[13798]: req:2 'connectivity-change': start running ordered scripts...
Jun 09 00:15:26 amnesia kernel: iwlwifi 0000:01:00.0: Radio type=0x1-0x2-0x0
Jun 09 00:15:26 amnesia gnome-shell[10955]: Object St.Icon (0x5bf5986404c0), has been already deallocated — 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.
Jun 09 00:15:26 amnesia org.gnome.Shell.desktop[10955]: == Stack trace for context 0x5bf596804240 ==
Jun 09 00:15:26 amnesia org.gnome.Shell.desktop[10955]: #0   5bf5991e30e0 i   /usr/share/gnome-shell/extensions/torstatus@tails.boum.org/extension.js:64 (7d2a40d74160 @ 67)
Jun 09 00:15:26 amnesia org.gnome.Shell.desktop[10955]: #1   7ffdd6d01a80 b   resource:///org/gnome/gjs/modules/_legacy.js:82 (7d2a41eb0b80 @ 71)
Jun 09 00:15:26 amnesia org.gnome.Shell.desktop[10955]: #2   5bf5991e3058 i   /usr/share/gnome-shell/extensions/torstatus@tails.boum.org/extension.js:78 (7d2a40d74280 @ 92)
Jun 09 00:15:26 amnesia org.gnome.Shell.desktop[10955]: #3   7ffdd6d02a60 b   resource:///org/gnome/gjs/modules/_legacy.js:82 (7d2a41eb0b80 @ 71)
Jun 09 00:15:26 amnesia org.gnome.Shell.desktop[10955]: #4   7ffdd6d036d0 b   self-hosted:983 (7d2a41ef01f0 @ 515)
Jun 09 00:15:26 amnesia kernel: gnome-shell[10955]: segfault at 28 ip 00007d2a5ac68bea sp 00007ffdd6d009c0 error 4 in libst-1.0.so[7d2a5ac5b000+2c000]
Jun 09 00:15:26 amnesia kernel: Code: 48 89 d8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 31 db 48 83 c4 08 48 89 d8 5b 5d c3 0f 1f 40 00 41 54 55 48 89 f5 53 48 89 fb <4c> 8b 67 28 e8 7d 3b ff ff 48 8b 13 48 85 d2 74 05 48 3b 02 74 13

Then GNOME Shell is restarted and crashes again, apparently when the flag file torstatus monitors appears and the extension should update the icon:

Jun 09 00:15:32 amnesia systemd[1]: Starting Manage the flag file that indicates whether Tor has bootstrapped...
Jun 09 00:15:32 amnesia gnome-shell[13857]: Object St.Icon (0x63e9b035a750), has been already deallocated — 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.
Jun 09 00:15:32 amnesia kernel: gnome-shell[13857]: segfault at 28 ip 0000778770e1dbea sp 00007ffef01b2ad0 error 4 in libst-1.0.so[778770e10000+2c000]
Jun 09 00:15:32 amnesia kernel: Code: 48 89 d8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 31 db 48 83 c4 08 48 89 d8 5b 5d c3 0f 1f 40 00 41 54 55 48 89 f5 53 48 89 fb <4c> 8b 67 28 e8 7d 3b ff ff 48 8b 13 48 85 d2 74 05 48 3b 02 74 13
Jun 09 00:15:32 amnesia org.gnome.Shell.desktop[13857]: == Stack trace for context 0x63e9ae56e2c0 ==
Jun 09 00:15:32 amnesia org.gnome.Shell.desktop[13857]: #0   63e9ae923e10 i   /usr/share/gnome-shell/extensions/torstatus@tails.boum.org/extension.js:62 (77873dd74160 @ 36)
Jun 09 00:15:32 amnesia org.gnome.Shell.desktop[13857]: #1   7ffef01b3b10 I   resource:///org/gnome/gjs/modules/_legacy.js:82 (77873edb0b80 @ 71)
Jun 09 00:15:32 amnesia org.gnome.Shell.desktop[13857]: #2   63e9ae923d88 i   /usr/share/gnome-shell/extensions/torstatus@tails.boum.org/extension.js:75 (77873dd74280 @ 70)
Jun 09 00:15:32 amnesia org.gnome.Shell.desktop[13857]: #3   7ffef01b4a80 I   resource:///org/gnome/gjs/modules/_legacy.js:82 (77873edb0b80 @ 71)
Jun 09 00:15:32 amnesia org.gnome.Shell.desktop[13857]: #4   7ffef01b56f0 b   self-hosted:983 (77873edf01f0 @ 515)
Jun 09 00:15:32 amnesia systemd[1]: Started Manage the flag file that indicates whether Tor has bootstrapped.

Finally, gnome-session gives up restarting GNOME Shell, which explains what alienpup sees (apart of the focused application, the desktop is unresponsive):

Jun 09 00:15:32 amnesia gnome-session-binary[10811]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 11
Jun 09 00:15:32 amnesia gnome-session-binary[10811]: Unrecoverable failure in required component org.gnome.Shell.desktop
Jun 09 00:15:32 amnesia gnome-session-binary[10811]: WARNING: App 'org.gnome.Shell.desktop' respawning too quickly
Jun 09 00:15:32 amnesia gnome-session[10811]: Unable to init server: Could not connect: Connection refused
Jun 09 00:15:32 amnesia gnome-session-f[14115]: Cannot open display: 

I’ve asked alienpup and sajolida to test again:

• with xorg-driver=intel (just in case the icon deallocation is hardware specific, which I strongly doubt)
• after disabling our torstatus GNOME Shell extension

#7 Updated by lamby 2019-06-17 20:29:02

@intrigeri

> I think that the _updateIcon method in torstatus should not assume that the this._icon object still exists

I worry this is papering over the problem. What we in-effect have is a double-free here, no? :) Also note that we are in a strange non-typical Javascript land here - usually if this was the web we would just do if (typeof this._icon === 'undefined') { return; } but I think what is happening is that this._icon does indeed /exist/ in terms of being a Javascript object at the time but the underling C/GNOME/blah binding it refers to does not, so doing anything with it breaks as above. I do not know how to test whether the ref exists from GNOME (or Gio?) scripts and my search fu is failing me right now…

#8 Updated by intrigeri 2019-06-18 08:08:01

intrigeri wrote:
> I’ve asked alienpup and sajolida to test again:
>
> * with xorg-driver=intel (just in case the icon deallocation is hardware specific, which I strongly doubt)
> * after disabling our torstatus GNOME Shell extension

sajolida did 3-5 suspend+resume cycles, with all for combinations of torstatus enabled/disabled and xorg-driver=intel or not, and could not reproduce the GNOME Shell crash anymore. So no new useful data point here except sajolida says GNOME Shell sometimes crashes when waking up the screen (that the screen locker puts to sleep), while the system has not been fully suspended.

#9 Updated by intrigeri 2019-06-18 09:09:58

Dear @lamby,

>> I think that the _updateIcon method in torstatus should not assume that the this._icon object still exists

> I worry this is papering over the problem.

This is fair.

> What we in-effect have is a double-free here, no? :)

More like a use-after-free, no?

> I think what is happening is that this._icon does indeed /exist/ in terms of being a Javascript object at the time but the underling C/GNOME/blah binding it refers to does not

Full ACK. There are many similar bug reports about plenty of other GNOME bits and extensions on the web. One thing I’ve noticed while browsing them is that apparently, an extension should basically assume it’s disabled/enabled when locking/unlocking the screen (and thus, when suspending/resuming); at least, that’s how other projects have fixed extremely similar issues.

To confirm this assumption, I guess we could log something when disable() and _destroy() are called.

Random guess: this._monitor_changed_signal_id is triggered on a partially destroyed instance of TorStatusIndicator. I’m wondering I see that we call a destroy() method:

function disable() {
tor_status_indicator.destroy();
}

… while in the TorStatusIndicator class there’s a _destroy() method?

In other words, I wonder if our _destroy() method, that disconnects the file monitor, is ever called.

#10 Updated by lamby 2019-06-18 09:12:48

> More like a use-after-free, no?

Ye, you got me. :)

> In other words, I wonder if our _destroy() method, that disconnects the file monitor, is ever called.

Indeed, that was my roughly brief reading of it too but (further) was unlikely to be solved abstractly by “just” thinking or analysing the code itself - I bet there are a myriad of timing issues when unsuspending as well as whether it has been called at all… :/