=== maclin1 is now known as maclin | ||
mardy | seb128: hi! Do you happen to know where apps store their logs under unity8 (zesty)? | 07:37 |
---|---|---|
seb128 | mardy, hey, no idea, try journalctl maybe? | 07:37 |
mardy | seb128: yep, I tried "journalctl --user" but it says no journals were found | 07:39 |
seb128 | mardy, try the system one maybe, otherwise I don't know | 07:39 |
seb128 | but Saviq and others probably do | 07:39 |
mardy | seb128: yep, thanks (just pinged you as I saw you logging in :-) ) | 07:40 |
seb128 | np! | 07:40 |
mardy | Saviq: hi! Do you know where to find the logs? ^ | 07:40 |
=== maclin1 is now known as maclin | ||
=== maclin1 is now known as maclin | ||
Saviq | mardy, they are launched as systemd services, so if anywhere, it would be in journald | 09:17 |
Saviq | mardy, yeah, they are, but you need to give the full unit name: | 09:18 |
Saviq | $ journalctl --user-unit ubuntu-app-launch-application-legacy-ubuntu-system-settings-.service | 09:18 |
Saviq | not sure why plain `$ journalctl --user` doesn't give the same | 09:18 |
tsdgeos | Saviq: Mirv: didn't we already fix https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1641175 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1630906 ? | 09:56 |
ubot5 | Ubuntu bug 1641175 in unity8 (Ubuntu) "unity8 fails to build in arm64 because of tests segfault" [Critical,Confirmed] | 09:56 |
ubot5 | Ubuntu bug 1630906 in qtdeclarative-opensource-src (Ubuntu RTM) "QML segfault on arm64 due to builder kernel change" [Undecided,In progress] | 09:56 |
mardy | Saviq: ah, thanks a lot! | 09:57 |
Saviq | tsdgeos, no, Mirv found i386 issues | 09:57 |
tsdgeos | ah right | 09:57 |
tsdgeos | want me to try to have a quick look? | 09:58 |
Saviq | Mirv would have to tell where he's at | 09:58 |
tsdgeos | Saviq: should we kill https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1367822 ? | 09:59 |
ubot5 | Ubuntu bug 1367822 in Ubuntu UX "[Scopes] Process required to pin a shortcut to the launcher does not fit users mental model" [High,In progress] | 09:59 |
Saviq | tsdgeos, right, doing | 09:59 |
Mirv | Saviq: tsdgeos: it's still sitting in https://bileto.ubuntu.com/#/ticket/2519 - as you can see in unity8 i386 (and armhf actually) tests at https://bileto.ubuntu.com/excuses/2519/xenial.html , there are new segfaults. I don't see anything remotely possibly having a fix in the 5.6 branch that I could additionally cherry-pick, so kind of only hope is that the final 5.6.3 will magically fix those issues | 10:03 |
Mirv | tsdgeos: this was the thing where I showed that there are only 1.5 pages sof commits since 5.6.2 in qtdeclarative: http://code.qt.io/cgit/qt/qtdeclarative.git/log/?h=5.6 | 10:04 |
Mirv | three are picked, all hinted by upstream originally some months ago | 10:05 |
tsdgeos | Saviq: want me to try to update https://unity.ubuntu.com/getinvolved/development/unity8/ yet again? | 10:08 |
Saviq | tsdgeos, I'd like us focus on the current buglist first http://goo.gl/nTYdDQ | 10:13 |
tsdgeos | ok | 10:13 |
Saviq | if there's any that are not pwned, please take it | 10:14 |
tsdgeos | Saviq: if you have some time, have a look at my last comment on https://bugs.launchpad.net/canonical-devices-system-image/+bug/1525285 | 10:15 |
ubot5 | Ubuntu bug 1525285 in clutter-gst-3.0 (Ubuntu) "inspecting clutter plugin hangs outside X11" [High,Triaged] | 10:15 |
tsdgeos | not convinced it's a bug anymore (or maybe some xmir defaulting "fixed" it) | 10:15 |
Saviq | tsdgeos, try taking a screenshot with unity8 ;) | 10:16 |
Saviq | having first removed the registry | 10:16 |
tsdgeos | ok | 10:20 |
tsdgeos | 10% battery and can't find the power brick :D | 10:20 |
tsdgeos | ok, at my parents place, bus | 10:27 |
Saviq | tsdgeos, http://paste.ubuntu.com/24214533/ is what I get in unity8 when trying to take a screenshot without a registry present | 10:29 |
Saviq | although it doesn't look like it's clutter responsible necessarily http://paste.ubuntu.com/24214540/ | 10:31 |
Saviq | maek that http://paste.ubuntu.com/24214544/ | 10:32 |
Saviq | greyback_, is thread 12 waiting for thread 27 is waiting for thread 12 is waiting for thread 27 is waiting for thread 12... you know what I mean ↑? | 10:33 |
greyback_ | Saviq: I do. Is this a multimonitor setup? | 10:36 |
Saviq | greyback_, it is | 10:36 |
greyback_ | Saviq: ok, that makes sense. Threads 26&27 are render threads, they're both waiting inside processEventsAndWaitForMore which is ok, they're waiting to be told to render something new | 10:37 |
greyback_ | Saviq: thread 12 being blocked there is bad, means Qt GUI thread blocked | 10:38 |
Saviq | greyback_, context: was trying to take a screenshot, hence gst in thread 27 trying to redo the registry | 10:38 |
Saviq | and I'm thinking while doing so, it tried to connect to Mir and we're trying to see if we authorize it in thread 12? | 10:38 |
Saviq | hmm but we shouldn't deadlock on that should we | 10:39 |
greyback_ | Saviq: possible. I don't get why taking a screenshot causes registry "redo" though | 10:39 |
Saviq | greyback_, because there wasn't any yet | 10:39 |
Saviq | am trying to see where we are with bug #1525285 | 10:39 |
ubot5 | bug 1525285 in clutter-gst-3.0 (Ubuntu) "inspecting clutter plugin hangs outside X11" [High,Triaged] https://launchpad.net/bugs/1525285 | 10:39 |
Saviq | greyback_, and taking a screenshot causes sound | 10:40 |
greyback_ | Saviq: ah ok, understood | 10:40 |
greyback_ | then we're in a pickle | 10:41 |
greyback_ | need to do session authorization outside the Qt GUI thread | 10:41 |
greyback_ | which is do-able I think | 10:42 |
greyback_ | I'm still a bit surprised gst connects to mir | 10:43 |
Saviq | greyback_, yeah well that might be part of the bug | 10:47 |
Saviq | it actually spawns gst-plugin-scanner | 10:49 |
Saviq | and yeah, it's the clutter plugin that tries to connect to mir | 10:52 |
greyback_ | and this is all blocking? ugg | 10:53 |
Saviq | http://pastebin.ubuntu.com/24214612/ | 10:53 |
Saviq | that's gst-plugin-scanner's trace | 10:54 |
Saviq | tsdgeos, ↑ | 10:54 |
Saviq | so the problem only seems to exist now if the registry is being scanned from within unity8 | 10:54 |
Saviq | but why would clutter contact the display server in the first place... | 10:54 |
tsdgeos | same-ish as mine, no? | 10:54 |
tsdgeos | upstream quickly waved off to gtk | 10:55 |
tsdgeos | see the upstream bug i linked | 10:55 |
tsdgeos | i was thinking while on the bus | 10:55 |
tsdgeos | is it a deadlock because Unity8 wants to connect to Unity8 ? | 10:56 |
Saviq | tsdgeos, no, unity8 → gst-plugin-scanner → unity8 | 10:56 |
Saviq | so... -ish | 10:56 |
Saviq | brb | 10:56 |
Saviq | so yeah, there are a bunch of problems here - gst blocking on registry generation (suppose it has to, to actually be able to play), clutter connecting to the display server, unity8 not able to reply to a auth request when gst is blocking it | 11:06 |
Saviq | but we'd have rejected the connection anyway | 11:09 |
tsdgeos | that's fine | 11:10 |
tsdgeos | if you run gst-plugin-scanner in a user that has no connection | 11:10 |
tsdgeos | it suceeds | 11:10 |
Saviq | tsdgeos, well, not fine, as your own tests shows - if you run under a user that *does* run Mir, it fails (hangs?) | 11:13 |
Saviq | and that's not because the unity8 → unity8 loop | 11:13 |
Saviq | https://bugzilla.gnome.org/show_bug.cgi?id=780193#c5 | 11:13 |
ubot5 | Gnome bug 780193 in Backend: Mir "inspecting clutter plugin hangs outside X11" [Normal,New] | 11:13 |
tsdgeos | yep | 11:13 |
tsdgeos | actually since i was running it from a VT | 11:14 |
tsdgeos | i'm not convinced it got stuck | 11:14 |
tsdgeos | or was hit by "unity8 is not focused so it's suspended" | 11:14 |
tsdgeos | want to try to reproduce it again from unity8 itself | 11:14 |
Saviq | when ran from a terminal, it does hang here... but so does it under unity7 | 11:20 |
Saviq | with -l that is | 11:20 |
Saviq | ah but that's likely for RPC | 11:21 |
tsdgeos | Saviq: yeah, running gst-inspect-1.0 from konsole inside unity8 it's "ok" | 11:22 |
tsdgeos | yeah, it hangs in a VT because untiy8 is suspended | 11:23 |
tsdgeos | if i swtich to unity8 VT and come back | 11:23 |
tsdgeos | it finished | 11:23 |
tsdgeos | so i'd say the main problem is really "unity8 not able to reply to a auth request when gst is blocking it" | 11:23 |
tsdgeos | and i guess this one is actually in our reach to fix | 11:23 |
Saviq | tsdgeos, well, yeah, -ish, since the clutter plugin gets rejected | 11:24 |
tsdgeos | which is fine | 11:24 |
tsdgeos | we don't want/need clutter | 11:24 |
Saviq | sure we don't? | 11:24 |
Saviq | what if a user switches to a gnome-shell session then | 11:25 |
Saviq | I mean, sure, fine, but meh | 11:25 |
tsdgeos | that'd be a problem for gst to fix | 11:25 |
tsdgeos | not assuming that if featureY failed today, it will fail forever | 11:26 |
tsdgeos | out of scope for our bug if you ask me | 11:26 |
Saviq | tsdgeos, well, yes, *we* need to fix the auth block | 11:26 |
Saviq | doesn't change the fact that the bug's there in gst-clutter | 11:27 |
Saviq | I've updated the description | 11:31 |
Saviq | greyback, so I've updated bug #1525285 - while I still think this is a gst-clutter bug, we need to try and make sure things like that don't bite us, and do the auth in a separate thread (and we should be able to, right? at most, we're simply talking to UAL for that?) | 11:36 |
ubot5 | bug 1525285 in qtmir (Ubuntu) "Unity8 deadlock when trying to screenshot without a current gst registry" [High,Triaged] https://launchpad.net/bugs/1525285 | 11:36 |
Saviq | it'd be good to get it done for Zesty release | 11:37 |
greyback | Saviq: yep we should be able to. Just requires some shimmying of code around and a little thread safety thinking | 11:38 |
tsdgeos | Mirv: i'm 34.65% you need a uitk rebuild in that silo | 11:45 |
tsdgeos | since it's using some qv4 private classes affected by the patches | 11:45 |
Mirv | tsdgeos: oh, thanks for the tip, trying that out | 12:12 |
tsdgeos | Mirv: rebuild fixes the crash locally, you may need to rebuild anything that depends on qtdeclarative5-private-dev | 13:19 |
tsdgeos | to be on the safe side | 13:19 |
=== JanC is now known as Guest30327 | ||
=== JanC_ is now known as JanC | ||
=== dandrader is now known as dandrader|afk | ||
=== dandrader|afk is now known as dandrader | ||
=== jjb is now known as oao | ||
=== oao is now known as jjb | ||
=== JanC_ is now known as JanC | ||
=== dandrader is now known as dandrader|afk | ||
=== dandrader|afk is now known as dandrader | ||
=== dandrader is now known as dandrader|afk | ||
=== dandrader|afk is now known as dandrader | ||
=== Saviq_ is now known as Saviq |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!