[09:12] <duflu> Does anyone think we might be overloading the AsioMainLoop thread?
[09:13] <duflu> I'm assuming it's just one thread. Looks like it (one per run())
[09:13] <duflu> Especially if we submit jobs that might entail some blocking or IO, that might explain a lot
[09:14] <duflu> Although that's an easy theory to test
[14:08] <kdub> I got a failure with linking libmirprotobuf and building qtmir (sbuild/armhf), is this known?
[14:09] <kdub> kinda looks like https://bugs.launchpad.net/mir/+bug/1388686
[14:10] <kgunn> kdub: i hadn't heard of this
[14:12]  * kdub investigates further
[14:13] <kgunn> dandrader: do you cross build qtmir ?
[14:13] <dandrader> kgunn, never
[14:13] <dandrader> did
[14:15] <kdub> I havent gotten a cross build working, usually use emulated
[14:15] <kgunn> alf_: so reading duflu's mail about performance and thread blocking...am i wrong in thinking, there's not really a problem there?
[14:15] <kgunn> i mean if a client blocks for some very small amount of time to feed the server that seems normal
[14:16] <kgunn> or do i not understand what he's describing
[14:16] <kgunn> (blocking on the server side for the full frame creation incl gpu time would be a problem)
[14:17] <anpok_> hm could frame dropping wait on a lock
[14:18] <anpok_> but it shouldnt drop in that use case..
[14:19] <alf_> kgunn: I am not 100% sure either, but think what it came down to is that the thread blocking seen in the main loop is actually correct behavior (not waking up more often than required). The problem seems to be that we are not waking as often as we should in some cases.
[14:20] <kgunn> ah, ok thanks...so it's not a blocking prob, it's a "remained idle and i expected it to run" prob
[14:21] <alf_> kgunn: i.e. the delays in the main loop are the effect not the cause
[14:21] <anpok_> ah run_once includes the wait for events..
[14:21] <alf_> kgunn: yes, that's my understanding, but I haven't looked in depth
[14:22] <kgunn> alf_: makes me wonder what glib spike would reflect
[14:22] <kgunn> guess we'll find out as we conclude landing
[14:23] <alf_> kgunn: unless there is a problem with either our asio or glib implementations, the behavior should be similar in terms of blocking
[14:23] <alf_> kgunn: yes, getting close
[15:12] <Saviq> hey folks, we got bug #1377332
[15:12] <Saviq> Josh has been trying to look into it, but I managed to get it today
[15:13] <Saviq> and there's an interesting trace: http://pastebin.ubuntu.com/8942307/
[15:13] <Saviq> recvmsg seems stuck
[15:13] <Saviq> in thread 29
[15:15] <Saviq> I still have the phone in that state if there's more data that could be interesting
[15:16] <greyback> Saviq: glib2.0 debug symbols please
[15:17] <greyback> Saviq: I'd like to know what thread1 is doing
[15:17] <Saviq> greyback, hmm thought I had them, coming right up
[15:20] <Saviq> greyback, http://pastebin.ubuntu.com/8942429/
[15:20] <Saviq> stuck on socket :/
[15:21] <greyback> Saviq: hmm, UAL symbols just to be sure what point qtmir is blocking at
[15:21] <Saviq> greyback, yeah, was just getting them
[15:21] <greyback> :)
[15:23] <Saviq> greyback, http://pastebin.ubuntu.com/8942460/
[15:24] <greyback> what went wrong there
[15:24] <greyback> Saviq: we need ted
[15:24] <Saviq> greyback, fwiw I just pressed my last passcode number
[15:25] <greyback> Saviq: is unity8-dash running?
[15:25] <Saviq> greyback, yes, SIGCONT'ed even
[15:26] <Saviq> greyback, with qtmir http://pastebin.ubuntu.com/8942528/
[15:26] <Saviq> yikes that's a deep bt
[15:27] <greyback> Saviq: it appears upstart isn't replying to the request UAL is putting to it, so everything blocks
[15:27] <greyback> why that happens... I can't say
[15:28] <Saviq> tedg, you about?
[15:31] <tedg> Saviq, Depends on the question. Easy or hard?
[15:32] <tedg> Hmm, that's not good.
[15:33] <tedg> Not sure how we can block on the cgmanager connection.
[15:33] <tedg> Saviq, How did you get there? Long running or a first time thing?
[15:33] <ogra_> greyback, https://bugs.launchpad.net/bugs/1391076 ??
[15:34] <greyback> ogra_: bug not found..
[15:34] <ogra_> greyback, well, by the bot :P
[15:34] <greyback> oh I can see it, duh
[15:35] <ogra_> yeah, i didnt know what to file it against originally
[15:35] <ogra_> sounds a bit similar and i wouldnt mind duplicating it
[15:35] <ogra_> if someone confirms it is)
[15:36] <greyback> ogra_: yeah. Lockup never easy for me to repro, will keep at it
[15:36] <ogra_> though for me the whole UI stalls ... not sure that is what the bug describes
[15:36] <ogra_> (and i dont have any process consuming much)
[15:38] <Saviq> tedg, I was just using the phone for a bit
[15:38] <Saviq> tedg, have stopped/started some apps
[15:39] <Saviq> tedg, and then I tried to log in again, and after I tapped the last number in my passcode, it got stuck
[15:39] <Saviq> tedg, so it was probably trying to resume an app
[15:40] <tedg> Saviq, Hmm, okay. So it's probably talked to cgmanager before though, when all the other apps started.
[15:40] <Saviq> tedg, definitely, uptime is 2:15
[15:47] <tedg> Saviq, Do you have anything in your cgmanager log?
[15:48] <tedg> Saviq, /var/log/upstart/cgmanager*
[15:48] <tedg> Or cgproxy I guess, but I don't think it'd be there.
[15:56] <Saviq> tedg, http://pastebin.ubuntu.com/8942980/
[15:56] <tedg> Saviq, So assuming we can't find anything useful out from cgmanager, I think one of our only choices is to timeout on the connection. It'll be suboptimal, but at least Unity won't hang.
[15:57] <Saviq> tedg, sounds like a plan, it will reconcile itself after you stop and start an app again anyway, right?
[15:57] <tedg> Saviq, Yeah, we'd just miss a pause or resume, or worst case a connection on startup. But it seems to be rather rare.
[15:57] <Saviq> tedg, yeah, definitely better than hanging
[15:58] <tedg> It's going to make my code significantly less pretty though ;-)
[15:58] <kgunn> Saviq: so is this the same bug as ogra_ posted ?
[15:58] <Saviq> kgunn, symptoms are definitely the same
[16:01] <Saviq> tedg, could you comment on bug #1377332 please and add tasks as appropriate
[16:04] <tedg> k