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

Shell Hangs #549

Closed
Afsalmc opened this issue May 31, 2019 · 7 comments
Closed

Shell Hangs #549

Afsalmc opened this issue May 31, 2019 · 7 comments
Labels
needs info An issue that needs more information

Comments

@Afsalmc
Copy link

Afsalmc commented May 31, 2019

Describe the bug

Gnome Shell 3.28 Hangs for approx 20 sec while receiving first notification from connected device after boot . Issue is noted in Ubuntu 18.04.2 .

Steps To Reproduce:

  1. Boot Up system
  2. Receive first Notification from connected device
  3. Shell Hangs for about 20 sec .

Expected behavior

First notification from Paired mobile device is displayed immediately without shell Hanging after Booting up the Computer .

System Details (please complete the following information):

  • GSConnect version: 24
    • Installed from: GNOME Extensions Website
  • GNOME/Shell version: 3.28
  • Distro/Release: Ubuntu 18.04.2

GSConnect environment (if applicable):

  • Paired Device(s): Samsung Galaxy on7 Prime (Android 9)
  • KDE Connect app version: 1.12.7

Additional Notes:

Using Linuxium spin of Ubuntu 18.04.2 for Baytrail Devices

@andyholmes
Copy link
Collaborator

Hi, can you please try to generate a support log as described here?

This sounds like a bug which occurred in the version of GSConnect shipped in Ubuntu's APT repository. Can you confirm this is not installed?

@andyholmes andyholmes added the needs info An issue that needs more information label Jun 1, 2019
@andyholmes
Copy link
Collaborator

Closing due to lack of activity and information. Feel free to re-open if the issue persists and you can upload a log.

@Zap123
Copy link

Zap123 commented Jul 27, 2019

I'm not sure if it's the same issue as @Afsalmc, but sometimes when I receive a notification gnome-shell becomes unresponsive, the default ubuntu 18.04 dash to dock extension disappears for an instant and then everything returns to normal.

I have found a quite reliable method (works if you do it 2-3 times) to reproduce the issue:

  • click on the gnome's clock
  • clear all notifications
  • send a ping from kdeconnect android's app

gsconnectlog.txt
gsconnectissuen 549

@ferdnyc
Copy link
Member

ferdnyc commented Jul 27, 2019

@Zap123 's logs start here:

-- Logs begin at Tue 2019-05-07 17:51:20 CEST, end at Sat 2019-07-27 13:45:46 CEST. --
lug 27 13:45:01 CRON[9835]: pam_unix(cron:session): session opened for user root by (uid=0)
lug 27 13:45:01 CRON[9836]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
lug 27 13:45:01 CRON[9835]: pam_unix(cron:session): session closed for user root
lug 27 13:45:43 gnome-shell[2560]: Object Gio.Settings (0x559e54aa0fa0), 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
lug 27 13:45:43 gnome-shell[2560]: g_object_run_dispose: assertion 'G_IS_OBJECT (object)' failed
lug 27 13:45:43 org.gnome.Shell.desktop[2560]: == Stack trace for context 0x559e4ab87320 ==
lug 27 13:45:43 org.gnome.Shell.desktop[2560]: #0 0x559e4af49770 i   resource:///org/gnome/shell/ui/messageTray.js:235 (0x7fcb3ee9e4d8 @ 22)
lug 27 13:45:43 org.gnome.Shell.desktop[2560]: #1 0x7ffda617a180 I   resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7fcb840b5de0 @ 71)
lug 27 13:45:43 org.gnome.Shell.desktop[2560]: #2 0x559e4af496d0 i   resource:///org/gnome/shell/ui/messageTray.js:812 (0x7fcb3eea14d8 @ 28)
lug 27 13:45:43 org.gnome.Shell.desktop[2560]: #3 0x7ffda617ad60 I   resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7fcb840b5de0 @ 71)
lug 27 13:45:43 org.gnome.Shell.desktop[2560]: #4 0x559e4af49630 i   resource:///org/gnome/shell/ui/windowAttentionHandler.js:100 (0x7fcb3eb42f78 @ 42)
lug 27 13:45:43 org.gnome.Shell.desktop[2560]: #5 0x7ffda617b940 I   resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7fcb840b5de0 @ 71)
lug 27 13:45:43 org.gnome.Shell.desktop[2560]: #6 0x559e4af495b8 i   resource:///org/gnome/shell/ui/windowAttentionHandler.js:44 (0x7fcb3eb42ab0 @ 17)
lug 27 13:45:43 org.gnome.Shell.desktop[2560]: #7 0x7ffda617c540 I   resource:///org/gnome/gjs/modules/signals.js:128 (0x7fcb840d2230 @ 386)
lug 27 13:45:43 org.gnome.Shell.desktop[2560]: #8 0x559e4af49530 i   resource:///org/gnome/shell/ui/messageTray.js:479 (0x7fcb3ee9ef78 @ 22)
lug 27 13:45:43 org.gnome.Shell.desktop[2560]: #9 0x7ffda617d120 I   resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7fcb840b5de0 @ 71)
lug 27 13:45:43 org.gnome.Shell.desktop[2560]: #10 0x559e4af494b0 i   resource:///org/gnome/shell/ui/calendar.js:801 (0x7fcb3eead3c8 @ 22)
lug 27 13:45:43 org.gnome.Shell.desktop[2560]: #11 0x7ffda617dd10 I   resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7fcb840b5de0 @ 71)
lug 27 13:45:43 org.gnome.Shell.desktop[2560]: #12 0x7ffda617dde0 b   self-hosted:918 (0x7fcb840f12b8 @ 394)

A quick troll 'round the interwebs makes me think those logs (ignoring the unrelated sysstat cron job that pokes up right at the start) are likely just the normal aftermath of Gnome Shell segfaulting, with the actual crash happening prior to the start of the logs.

@Zap123 , any chance you could look at journalctl --user -b (assuming you haven't rebooted since this crash, since that'll show your journal starting from the most recent reboot), find the logs I listed above, and let us know what happened before that?

There's probably a point shortly before those tracebacks start getting logged, where gnome-shell / org.gnome.Shell itself crashes (which will have set off a flurry of broken pipes, object access failures, and tracebacks that your current logs kind of wake up right in the middle of). What we'd really be most interested in is whatever was happening (log-wise) just before everything starts going to shell.

This sounds similar enough that I'm going to reopen this report, on the assumption it's probably the same issue.

@ferdnyc ferdnyc reopened this Jul 27, 2019
@ferdnyc
Copy link
Member

ferdnyc commented Jul 27, 2019

Unfortunately, so far most of what I've found (in terms of related logs/reports) are issues filed with other shell extensions by Ubuntu users experiencing similar issues, but the extension developers never really making much progress in figuring out how (or even IF) they're actually causing them.

So, this may be GSConnect's induction into a really lame club. But, hey — there's company. 👍

@Zap123
Copy link

Zap123 commented Jul 27, 2019

Hi @ferdnyc, thanks for your prompt response!

I have tested a few things to see if something would change but it didn't:

  • disabling all extensions except gsconnect
  • using the gnome-session instead of the ubuntu one
  • using gnome-session on wayland

I had already rebooted therefore I reproduced the issue from a fresh session and using journalctl I have saved the log that you can find attached.

This is the error that happens exactly before the crash:

lug 27 19:55:56 ghv gnome-shell[4071]: Object Meta.Background (0x55ce6b4cf300), 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

I have found an upstream bug report that has been fixed 4 months ago, It's probably not in Ubuntu yet but it seems the same problem.

Anyway it seems that this bug affect gsconnect but it's not only a problem contingent on this extension (even though in my case it happens only with gsconnect).

https://gitlab.gnome.org/GNOME/gnome-shell/issues/470

I think you can close this issue again, but thanks for your assistance.
I have reported this issue on Ubuntu's bug report
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1838152

gsconnect.log

@ferdnyc
Copy link
Member

ferdnyc commented Jul 27, 2019

There's a quote you always want to find while reading through a bug report:

I'm no longer sure of anything.

Thanks for the update, @Zap123. I agree it sounds more and more like this isn't really a GSConnect issue, just an issue GSConnect happens to be triggering. Re-closing like one of those sandwich baggies with the plastic zipper.

@ferdnyc ferdnyc closed this as completed Jul 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs info An issue that needs more information
Projects
None yet
Development

No branches or pull requests

4 participants