[13:48] <mterry> 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] <dandrader> mterry, only tests
[13:51] <mterry> dandrader: we can't disable lttng during runtime?  (like during tests?)
[13:51] <dandrader> 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] <dandrader> mterry, I think that would involve rebuilding it all without lttng
[13:52] <mterry> 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] <mterry> 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] <dandrader> mterry, it deadlocks right off the bat, on startup
[13:57] <mterry> Oh I see, you said no calls have to happen
[13:57] <dandrader> mterry, as I said, not call to any libcontent-hub code happens. only linking against it is needed
[13:58] <dandrader> 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] <dandrader> 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] <dandrader> *no build
[14:04] <mterry> 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] <dandrader> mterry, don't ask me. I've never used that tool :D
[14:07] <mterry> dandrader: hmm...  maybe it would work with something like "lttng create testing-session && lttng stop && make check"
[14:10] <dandrader> mterry, ok. will try
[14:10]  * mterry hopes, but isn't very familiar with lttng either
[14:40] <josharenson> tsdgeos: you're still seeing autosroller issues?
[14:40] <tsdgeos> josharenson: yeah
[14:41] <josharenson> tsdgeos: same issue? is it related to the patch I pushed on Friday?
[14:41] <tsdgeos> i don't know
[14:42] <tsdgeos> let me record a video
[14:42] <tsdgeos> it's hard-ish to explain
[14:42] <josharenson> tsdgeos: ok
[15:05] <josharenson> tsdgeos: cimi dash meeting?
[15:05] <tsdgeos> josharenson: cimi is on hols, i can join, give me a min
[15:05] <josharenson> ok
[15:18] <josharenson> 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] <josharenson>  
[15:20]  * tsdgeos checks
[15:22] <tsdgeos> josharenson: ok, it doesn't hang really
[15:22] <tsdgeos> it'll just take a long time
[15:22] <josharenson> tsdgeos: to timeout?
[15:22] <tsdgeos> yes
[15:23] <tsdgeos> because we timeout by faketime
[15:23] <tsdgeos> we don't really count time
[15:23] <tsdgeos> just do something
[15:23] <tsdgeos> then wait 50ms
[15:23] <tsdgeos> and said we're at 950ms
[15:23] <tsdgeos> +50ms i mean
[15:23] <tsdgeos> thing is, findChild also has it's own timeout
[15:24] <josharenson> tsdgeos: humm perhaps I just haven't had the patience to see the timeout?
[15:24] <tsdgeos> so basically you're putting the 5fake-sec timeout of findChild inside the 5fake-sec of tryCompareFunction
[15:24] <tsdgeos> and it probably amounts to "a lot"
[15:24] <josharenson> i see
[15:24] <tsdgeos> let me make sure though
[15:24] <tsdgeos> though you're right this may be what's causing the timeout
[15:24] <josharenson> tsdgeos: I hope so..
[15:52] <tsdgeos> josharenson: confirmed it does time out at the end
[15:52] <tsdgeos> ~30 min or so
[15:52] <josharenson> tsdgeos: goodness...
[15:52] <josharenson> tsdgeos: ok
[16:18] <sil2100> 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] <Saviq> sil2100, I suppose you can just upload that change directly (we do have a qtmir landing for OTA13 under QA now)
[16:28] <sil2100> Saviq: ok, if you don't mind me doing that for xenial only then I shall proceed :)
[16:28] <sil2100> Saviq: if you could just include this change with the next release (or sync trunk later)
[16:29] <Saviq> sil2100, could you wait for https://trello.com/c/x4GiBaXH/3590-1864-ubuntu-landing-067-qtmir-qtubuntu-saviq to go through?
[16:29] <Saviq> otherwise we'd need to rebuild
[16:29] <sil2100> hm, ok
[16:29] <Saviq> it's small and top of QA queue, so hopefully will get through soon
[16:57] <mterry> dandrader: so I tried the lttng create / lttng stop thing.  Didn't work
[16:57] <dandrader> mterry, me too
[16:57] <dandrader> mterry, got a better stacktrace though
[16:58] <dandrader> mterry, added to the MP description of the opt-in branch
[16:58] <dandrader> mterry, lttng is deadlocking on its lib init
[16:58] <mterry> dandrader: does content-hub use lttng too?
[16:58] <dandrader> mterry, no
[17:05] <mterry> dandrader: is it just armhf or also arm64?
[17:05] <dandrader> mterry, I could only reproduce it on arm, but IIRC kenvandine told me that in CI it happened also on other archs
[17:05] <mterry> ah
[17:06] <dandrader> mterry, armhf in my case
[17:06] <mterry> I've only tried armhf, but I seem to get deadlocked in QtEventFeederTest
[17:06] <mterry> I assume that's the place
[17:10] <mterry> 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] <dandrader> mterry, It's gonna make life harder for developers wanting to do lttng-based performance measurements
[17:12] <dandrader> being mr. obvious....
[17:12] <mterry> dandrader: yeah but we don't do anything automated with that during our QA or anything do we?
[17:12] <dandrader> mterry, but I don't know any details on who uses lttng and when....
[17:13] <mterry> 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] <dandrader> mterry, content-hub peaple == kenvandine. no, he doesn't
[17:15] <mterry> The MP's code itself looks fine
[17:18] <dandrader> 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] <mterry> dandrader: I just approved the branch.  I think we can regress lttng for now without the sky falling down
[17:21] <mterry> dandrader: I'm under the impression that the new content-hub stuff was fairly high priority, so I'd rather unblock that
[17:21] <dandrader> mterry, ok, thanks
[17:22] <mterry> dandrader: sorry for being so hesitant with your MP, just seemed like a drastic measure.  But I came around  :)
[17:23] <dandrader> 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] <mterry> dandrader: yeah more annoying but not debilitating
[17:24] <mterry> 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] <dandrader> mterry, anything stopping you from top-approving what you already approved on review?
[17:25] <mterry> dandrader: uh not on the optin-lttng one, just top-approved that
[17:25] <mterry> let me see on the others
[17:25] <mterry> Sometimes I forget to topapprove
[17:26] <mterry> dandrader: there done, thanks
[17:27] <Saviq> dandrader, mterry, there's one thing where this might be a problem... the automated KPI measurements
[17:27] <Saviq> like for timing app startup
[17:28]  * Saviq checks with cachio
[20:36] <kaisoz> hi