=== JanC is now known as Guest45177 === JanC_ is now known as JanC === dpm is now known as dpm-afk === dpm-afk is now known as dpm [13:48] dandrader: switching here, where I have a bouncer and don't have to worry about internet shortages. For the lttng patch... So tests were deadlocking on arm. Only tests, we didn't have problems with normal production envs? [13:49] mterry, only tests [13:51] dandrader: we can't disable lttng during runtime? (like during tests?) [13:51] mterry, lttng deadlocks waiting on some mutex when the binary is linked against libcontent-hub and you have at least one code line refering to it. no calls to any libcontent-hub API has to happen for the lttng deadlock to take place [13:52] mterry, I think that would involve rebuilding it all without lttng [13:52] dandrader: well one hack would be an LD_PRELOAD library that stubs out the lttng traceback call. But I'm shocked that there wouldn't be an env flag to control it... /me looks real quick [13:56] dandrader: does it deadlock once you go into the libcontent-hub API? We could use -finstrument-functions-exclude-function-list to avoid instrumenting those calls... [13:57] mterry, it deadlocks right off the bat, on startup [13:57] Oh I see, you said no calls have to happen [13:57] mterry, as I said, not call to any libcontent-hub code happens. only linking against it is needed [13:58] mterry, unless libcontent-hub does some sneaky call on startup like initializing some global var or something.... my backtrace diddn't didn't go very deed due to missing symbols. will keep digging.... [13:59] mterry, but at least this opt-in branch unblocks us. otherwise not build would be possible as tests are run on package building [13:59] *no build [14:04] dandrader: there do seem to be a lot of tracing control options via the lttng command, but I think they all assume a running tracing session, rather than modifying tracing ahead of time? [14:05] mterry, don't ask me. I've never used that tool :D [14:07] dandrader: hmm... maybe it would work with something like "lttng create testing-session && lttng stop && make check" [14:10] mterry, ok. will try [14:10] * mterry hopes, but isn't very familiar with lttng either [14:40] tsdgeos: you're still seeing autosroller issues? [14:40] josharenson: yeah [14:41] tsdgeos: same issue? is it related to the patch I pushed on Friday? [14:41] i don't know [14:42] let me record a video [14:42] it's hard-ish to explain [14:42] tsdgeos: ok === dandrader is now known as dandrader|afk [15:05] tsdgeos: cimi dash meeting? [15:05] josharenson: cimi is on hols, i can join, give me a min [15:05] ok [15:18] tsdgeos: so if you pull lp:~josharenson/unity8/wide-dash/ (and its in a terrible state atm so ignore almost everything) you'll see that it hangs on line 285 of testDashContent because it can never find the "dashNavigation" object [15:18] [15:20] * tsdgeos checks [15:22] josharenson: ok, it doesn't hang really [15:22] it'll just take a long time [15:22] tsdgeos: to timeout? [15:22] yes [15:23] because we timeout by faketime [15:23] we don't really count time [15:23] just do something [15:23] then wait 50ms [15:23] and said we're at 950ms [15:23] +50ms i mean [15:23] thing is, findChild also has it's own timeout [15:24] tsdgeos: humm perhaps I just haven't had the patience to see the timeout? [15:24] so basically you're putting the 5fake-sec timeout of findChild inside the 5fake-sec of tryCompareFunction [15:24] and it probably amounts to "a lot" [15:24] i see [15:24] let me make sure though [15:24] though you're right this may be what's causing the timeout [15:24] tsdgeos: I hope so.. === dandrader|afk is now known as dandrader [15:52] josharenson: confirmed it does time out at the end [15:52] ~30 min or so [15:52] tsdgeos: goodness... [15:52] tsdgeos: ok [16:18] Saviq, dandrader: hey! Could we get https://code.launchpad.net/~vicamo/qtmir/build-qtmir-android-arm64/+merge/303760 released as soon as possible? [16:19] sil2100, I suppose you can just upload that change directly (we do have a qtmir landing for OTA13 under QA now) [16:28] Saviq: ok, if you don't mind me doing that for xenial only then I shall proceed :) [16:28] Saviq: if you could just include this change with the next release (or sync trunk later) [16:29] sil2100, could you wait for https://trello.com/c/x4GiBaXH/3590-1864-ubuntu-landing-067-qtmir-qtubuntu-saviq to go through? [16:29] otherwise we'd need to rebuild [16:29] hm, ok [16:29] it's small and top of QA queue, so hopefully will get through soon [16:57] dandrader: so I tried the lttng create / lttng stop thing. Didn't work [16:57] mterry, me too [16:57] mterry, got a better stacktrace though [16:58] mterry, added to the MP description of the opt-in branch [16:58] mterry, lttng is deadlocking on its lib init [16:58] dandrader: does content-hub use lttng too? [16:58] mterry, no [17:05] dandrader: is it just armhf or also arm64? [17:05] mterry, I could only reproduce it on arm, but IIRC kenvandine told me that in CI it happened also on other archs [17:05] ah [17:06] mterry, armhf in my case [17:06] I've only tried armhf, but I seem to get deadlocked in QtEventFeederTest [17:06] I assume that's the place [17:10] dandrader: so it's not like we can just disable armhf/arm64 tests to work around this while still using lttng. Does lttng get used in production (like, do we ever grab lttng logs from a device during our normal QA)? i.e. is this MP going to make life harder for us or just for people doing experimental testing? [17:12] mterry, It's gonna make life harder for developers wanting to do lttng-based performance measurements [17:12] being mr. obvious.... [17:12] dandrader: yeah but we don't do anything automated with that during our QA or anything do we? [17:12] mterry, but I don't know any details on who uses lttng and when.... [17:13] dandrader: have you asked content-hub people if they have any clue on this? [17:13] * mterry is trying to avoid landing this MP :) [17:13] mterry, content-hub peaple == kenvandine. no, he doesn't [17:15] The MP's code itself looks fine [17:18] mterry, we could wait until greyback returns on wednesday. seems he wrote most of those tracepoints. so he will have definite answers on usage [17:20] dandrader: I just approved the branch. I think we can regress lttng for now without the sky falling down [17:21] dandrader: I'm under the impression that the new content-hub stuff was fairly high priority, so I'd rather unblock that [17:21] mterry, ok, thanks [17:22] dandrader: sorry for being so hesitant with your MP, just seemed like a drastic measure. But I came around :) [17:23] mterry, from my POV, lttng is just a tool for devels when doing perf measurements. so the developer will now have to build qtmir himself before doing this kind of work [17:23] dandrader: yeah more annoying but not debilitating [17:24] I just wanted to make sure we weren't relying on the traces for anything besides experimental measurements. But we probably aren't [17:25] mterry, anything stopping you from top-approving what you already approved on review? [17:25] dandrader: uh not on the optin-lttng one, just top-approved that [17:25] let me see on the others [17:25] Sometimes I forget to topapprove [17:26] dandrader: there done, thanks [17:27] dandrader, mterry, there's one thing where this might be a problem... the automated KPI measurements [17:27] like for timing app startup [17:28] * Saviq checks with cachio [20:36] hi