| lool | so I reinstalled | 00:15 |
|---|---|---|
| lool | I got the same bug, but eventually it started | 00:15 |
| lool | the timing for pressing power button might matter | 00:16 |
| lool | racarr, kgunn: Pretty good news | 00:43 |
| lool | racarr, kgunn: It was borderline unstable, but now that I have hud with it, unity8 doens't crash anymore and boot is much more stable | 00:44 |
| lool | and everything is going in archive, one at a time | 00:44 |
| kgunn | lool: thanks man! | 01:17 |
| lool | kgunn: we have an issue with Hud | 01:18 |
| lool | kgunn: it's likely regressing the desktop | 01:18 |
| lool | kgunn: who would be able to help this? | 01:19 |
| lool | kgunn: I can land without it, but the results will be crappy | 01:19 |
| kgunn | lool: i assume its likely backend ?? ted would be best | 01:19 |
| kgunn | but doesn't seem on | 01:19 |
| lool | ted isn't up til 10 hours | 01:19 |
| lool | at least | 01:19 |
| kgunn | i know the issues were around the backend.... | 01:19 |
| lool | kgunn: So they added a platform-api backend | 01:20 |
| lool | kgunn: but on desktop I think we still want bamf | 01:20 |
| lool | but we dropped the bdep | 01:20 |
| kgunn | olli_: you on ?? ^ | 01:20 |
| kgunn | lool: thostr_ will be our best bet euro am | 01:20 |
| lool | ok | 01:21 |
| lool | I might try just adding the bdep | 01:21 |
| kgunn | you could get some sleep man and hit it in the morning | 01:21 |
| lool | yeah that too | 01:21 |
| kgunn | ricmm_: know anyone who knows about hud backend ?? ^ | 01:22 |
| racarr | back | 01:26 |
| racarr | seems like we definitely need bamf on desktop | 01:26 |
| racarr | lool: Good to hear image is working better with hud :D | 01:31 |
| racarr | is boot faster now too? | 01:31 |
| racarr | unity mir boot has been really slooow | 01:32 |
| racarr | and ive kind of suspected it has to do with errors about hud timeouts :p | 01:32 |
| olli_ | kgunn, yep | 01:45 |
| ricmm_ | kgunn: what happened? | 04:19 |
| ricmm_ | lool: I explicitly remember them saying "we both tested on desktop and phone and all works fine" | 04:20 |
| ricmm_ | lool: how did the MR land to trunk if it didnt have the bamf build dep? | 04:21 |
| ricmm_ | oh that was 3 hours ago | 04:22 |
| ricmm_ | crap | 04:22 |
| ricmm_ | his fix looking good | 04:22 |
| * ricmm_ -> zzz | 04:22 | |
| ricmm_ | kdub_: btw if you are still around | 04:25 |
| ricmm_ | kdub_: timings show that unity8 is busy blocking on buffer swap for about ~50ms per frame every other frame or so | 04:26 |
| ricmm_ | when rendering intensively | 04:26 |
| ricmm_ | racarr: kind of suspected? its a known thing since ever! | 04:31 |
| racarr | ricmm_: I guess I didnt know it was known because the one or two times I mentioned it no one said anything | 05:18 |
| racarr | and I was just like | 05:18 |
| racarr | ok move on! | 05:18 |
| RAOF | Ok. How have I managed to break egl-platform-mir? | 05:21 |
| duflu | RAOF: If you expect either a useful or amusing answer, I can't comment | 05:26 |
| duflu | racarr: (1) log off, else (2) Should bug 1233245 have Mir task? | 05:32 |
| ubot5 | bug 1233245 in Mir "[mir] key events not working through input devices (aka volume up/down)" [Critical,Triaged] https://launchpad.net/bugs/1233245 | 05:32 |
| ricmm_ | that bug is done afaik | 05:33 |
| duflu | ricmm_: BTW, the "50ms per frame", what device? | 05:33 |
| ricmm_ | mako | 05:33 |
| duflu | Oh. Mako should be better than that already | 05:33 |
| ricmm_ | theres a whole bug going on since the fencing was introduced to remove the tearing | 05:34 |
| ricmm_ | of course it *should* be | 05:34 |
| ricmm_ | but it hasnt been for a while | 05:34 |
| duflu | ricmm_: Yeah I was going to point you at that bug | 05:34 |
| tvoss | ricmm_, do you know if kdub tried switching to triple buffering while I was sleeping? | 05:35 |
| ricmm_ | tvoss: he didnt because apparently its not trivial to do | 05:35 |
| duflu | It occurs to me we have a significant bottleneck for touch with only one Android person on mir-team | 05:38 |
| RAOF | Dear bandwidth: where have you gone? :( | 05:49 |
| tvoss | didrocks, salut :) | 05:57 |
| didrocks | hey tvoss! | 05:57 |
| === Stskeepz is now known as Stskeeps | ||
| alf_ | lool: Which PPA contains the packages you used to test the fix to the close.qml crash (or have the packages reached the archive now)? | 06:35 |
| alf_ | lool: FWIW, with latest packages from the archive, I can't reproduce the crash anymore | 06:51 |
| RAOF | Bah! How was mesa mis-built? | 06:54 |
| * mlankhorst looks at excuse calendar | 06:56 | |
| mlankhorst | high pressure system failure | 06:57 |
| RAOF | Current theories include: cosmic rays, and clang. | 07:05 |
| mlankhorst | well a computer generated my excuse, so it's more reliable | 07:06 |
| duflu | But did cosmic rays affect the computer's output? | 07:06 |
| mlankhorst | we're not in space | 07:08 |
| duflu | Yes we are | 07:08 |
| * duflu goes to close the pod bay doors | 07:08 | |
| lool | alf_: it's all in #90 now | 08:02 |
| lool | alf_: racarr also gets the crash with latest tip | 08:02 |
| lool | alf_: I haven't tried again though | 08:02 |
| lool | alf_: maybe we landed something else from archive in image that we were lacking in testing | 08:02 |
| alf_ | lool: are you tests with mako or maguro | 08:06 |
| alf_ | ? | 08:06 |
| lool | alf_: haven't retried yet | 08:08 |
| lool | alf_: but if you're not seeing it with latest image great | 08:08 |
| lool | alf_: mako | 08:08 |
| alf_ | lool: ok, please give it another try when you can and let me know | 08:09 |
| lool | yup | 08:09 |
| lool | breakfast first | 08:09 |
| duflu | Hey I got my phone back!... How do I tell the image number (like "90")? | 08:49 |
| alf_ | duflu: cat /etc/media-info gives you some information, which you can use to find the image number | 08:50 |
| duflu | Ta | 08:50 |
| alf_ | duflu: of course, if you upgrade packages then this is not accurate any more | 08:52 |
| duflu | None seem to need upgrading... | 08:52 |
| tvoss | duflu, just reflash 90 :) | 08:53 |
| duflu | Did we kill off /tmp/mir_socket for unity8? | 08:53 |
| alf_ | duflu: look in $XDG_RUNTIME_DIR | 08:55 |
| alf_ | tvoss: a great problem with reflashing is that it deletes your development environment on the phone... it's a big waste of time to set it up again (get all the build-deps and -dbg(sym) packages, tools etc) | 08:57 |
| alan_g | alf_: +1 | 08:58 |
| alan_g | alf_: (and every time I think I understand it well enough to write a script something changes) | 08:58 |
| mlankhorst | hm anyone got something for me to look at? :P | 09:01 |
| alf_ | duflu: since you have a fresh image, do you have a moment to try https://bugs.launchpad.net/qtubuntu/+bug/1237052 ? | 09:04 |
| ubot5 | Error: Could not gather data from Ubuntu for bug #1237052 (https://launchpad.net/bugs/1237052). The error has been logged | 09:04 |
| duflu | alf_: Just put it away. I'll get back to it soon | 09:04 |
| tvoss | alan_g, https://code.launchpad.net/~thomas-voss/mir/add-pthread-linker-and-preprocessor-flags/+merge/190316 | 09:05 |
| alf_ | duflu: ok, btw you don't need to build anything, all fixes are in the archive now (check my last comment in that bug) | 09:05 |
| alan_g | tvoss: ack | 09:06 |
| tvoss | alan_g, waiting for CI to produce a testable package | 09:07 |
| alf_ | mlankhorst: nested Mir EGLImage support is still pending if you are interested ;) | 09:07 |
| mlankhorst | hm fine :P I'll poke it a bit more | 09:08 |
| alf_ | mlankhorst: I know that RAOF also took another look recently, but I am not sure if there was any progress | 09:10 |
| alf_ | RAOF: ^^ | 09:10 |
| alf_ | mlankhorst: (or at least that he wanted to take a look) | 09:10 |
| alan_g | tvoss: see https://code.launchpad.net/~thomas-voss/mir/add-pthread-linker-and-preprocessor-flags/+merge/190316/comments/436722 | 09:20 |
| tvoss | alan_g, duflu: it's about our own usage of pthread | 09:23 |
| duflu | tvoss: Can you detail the findings in the MP? | 09:23 |
| tvoss | duflu, the linked bug points to a very weird issue when a client tries to access the display configuration. Same happens for maliit server, which results in a lot of crashes during test automation | 09:24 |
| duflu | tvoss: Ah yes, spent time staring at those crashes today | 09:25 |
| tvoss | duflu, alan_g was able to reproduce the issue with a simple program using a std::unique_lock and not adding -pthred | 09:25 |
| tvoss | -pthread | 09:25 |
| alan_g | tvoss: the maliit server definitely pulls in pthreads | 09:25 |
| tvoss | alan_g, but: our client library is not compiled with that flag | 09:25 |
| tvoss | alan_g, and that's where the exception is thrown | 09:25 |
| duflu | tvoss: It's a theory, but I'm not convinced the Mir code is in need of any more "-pthreads", because it would be crashing immediately in the same way (which it doesn't) | 09:26 |
| alan_g | tvoss: what duflu said | 09:27 |
| tvoss | duflu, anyway, I'm only sticking to what the pthread manual suggests: add -pthread | 09:27 |
| tvoss | alan_g, duflu I'm basically waiting for jenkins to produce a testable package, thus the mp | 09:27 |
| alan_g | duflu: I don't think it hurts to try this | 09:27 |
| duflu | AFAIK -pthread just defines some macros and adds -lpthread to LDFLAGS | 09:27 |
| tvoss | duflu, implementation defined | 09:28 |
| tvoss | duflu, usually REENTRANT is set, but could be more complex for arm for example | 09:28 |
| duflu | alan_g: It's likely unnecessary bloat to link libraries not all binaries need. Though I suspect all Mir binaries do :/ | 09:28 |
| tvoss | duflu, if you have got a better idea to solve it -> go for it :) as long as the maliit server crashes are down to 0 in http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/90:20131010:20131010/4644/ | 09:29 |
| alan_g | duflu: If it fixes the problem that is a useful data point | 09:29 |
| tvoss | duflu, library bloat -> micro optimization, let's save that for later | 09:29 |
| duflu | Not worth arguing... | 09:29 |
| tvoss | duflu, ack | 09:30 |
| duflu | tvoss: Worth a try. Linked bug 1233988 too | 09:30 |
| ubot5 | bug 1233988 in platform-api (Ubuntu) "With Mir enabled: maliit-server crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,Confirmed] https://launchpad.net/bugs/1233988 | 09:30 |
| tvoss | duflu, thx | 09:31 |
| tvoss | duflu, can you give the package a spin, too, once ci spits it out? | 09:31 |
| duflu | tvoss: Sure but I think I'll be gone before then. | 09:32 |
| tvoss | duflu, ack :) | 09:32 |
| mlankhorst | alf_: huh? this is messed up | 09:40 |
| mlankhorst | oh nm :P | 09:40 |
| mlankhorst | alf_: so I assume the problem is in the nested mir somewhere, what is the image supposed to be for empty server, is it cleared? | 09:55 |
| alf_ | mlankhorst: yes, it's glClear()-ed, and then surfaces are composited | 09:56 |
| alf_ | lool: any luck with https://bugs.launchpad.net/qtubuntu/+bug/1237052 ? | 09:58 |
| ubot5 | Ubuntu bug 1237052 in qtubuntu "Apps that close themselves crash trying to use deleted EGL resources" [Undecided,Fix committed] | 09:58 |
| * duflu goes to play with vegetables | 10:01 | |
| tvoss | alan_g, https://jenkins.qa.ubuntu.com/job/mir-saucy-amd64-ci/831/console | 10:05 |
| tvoss | alan_g, is that known? | 10:05 |
| alan_g | tvoss: it wasn't to me - but https://bugs.launchpad.net/mir/+bug/1236698 | 10:07 |
| ubot5 | Ubuntu bug 1236698 in Mir "The following tests FAILED: 99 - memcheck(unit-tests.PublishedSocketConnector.*) (Failed)" [High,Triaged] | 10:07 |
| tvoss | alan_g, are you on it? | 10:09 |
| alan_g | tvoss: I'll add it to my list | 10:09 |
| lool | alf_: sorry didn't have time so far, but I do now | 10:12 |
| lool | alf_: and it worked! | 10:14 |
| lool | alf_: So I didn't have all the in distro changes when I tried that yesterday; I definitely had updated qtubuntu, and had an intermediate update of the mir packages, but not anything else | 10:14 |
| alf_ | lool: \o/ | 10:14 |
| lool | alf_: but now with image #90 it passed | 10:14 |
| lool | alf_: sorry for the delay in confirming | 10:15 |
| mlankhorst | alf_: huh.. | 10:15 |
| mlankhorst | why is dri2_create_image_khr_pixmap never called? :P | 10:15 |
| lool | alf_: I'm glad it's fixed after all, I almost didn't take qtubuntu in because of this | 10:15 |
| lool | alf_: updated bug too | 10:16 |
| alf_ | lool: thanks | 10:16 |
| mlankhorst | oh nm | 10:17 |
| alf_ | mlankhorst: :) | 10:18 |
| mlankhorst | alf_: hm if you use the native platform allocator for allocating buffers, what do you use for allocating the main window for nested? | 10:18 |
| alf_ | mlankhorst: the host mir allocates that and sends us the buffer (host mir uses platform_drm) | 10:19 |
| mlankhorst | yeah where's the code for importing that? | 10:19 |
| alf_ | mlankhorst: in mesa mir_advance_colour_buffer() | 10:26 |
| alf_ | mlankhorst: it uses the prime_fd from the buffer package | 10:27 |
| alf_ | mlankhorst: i.e. the host mir essentially sends the nested mir the prime fd for the "main window" surface, and nested mir passes that to mesa | 10:27 |
| mlankhorst | alf_: yeah but if the nested mir has no clients, does anything clear the contents of the bo? | 10:29 |
| alf_ | mlankhorst: yes, it is made current, and glClear() is called | 10:33 |
| alf_ | mlankhorst: prime_fd -> EGLSurface -> make_current -> glClear() | 10:33 |
| alf_ | mlankhorst: (at least this is what should be happening) | 10:34 |
| mlankhorst | can I somehow enable the spam from mir? | 11:11 |
| alf_ | jibel: I am checking the Mir Testing Notes document for bugs to look into... is bug 1237900 still private? | 11:11 |
| ubot5 | Error: Launchpad bug 1237900 could not be found | 11:11 |
| alf_ | jibel: or is it a typo? | 11:12 |
| alf_ | jibel: It's the last bug in Image 90:20131010:20131010 list | 11:12 |
| === hikiko is now known as hikiko|lunch | ||
| jibel | alf_, it is public now but invalid | 11:36 |
| asac | racarr: alf_: any news on the crashers front? | 11:53 |
| asac | Saviq: ^^ (unity8 crashes in particular i think) | 11:53 |
| alf_ | asac: Most of the crashes caused by the interaction with Mir have been fixed in the latest image | 12:01 |
| asac | we still see unity8 crashing http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/91:20131010.1:20131010/4658/webbrowser-app-autopilot/ | 12:02 |
| asac | this doesnt happen with SF | 12:03 |
| asac | just run webbrowser autopilot | 12:03 |
| alf_ | asac: that seems like https://bugs.launchpad.net/ubuntu/+source/platform-api/+bug/1233988, which is in progress from what I can see | 12:04 |
| ubot5 | Ubuntu bug 1233988 in platform-api (Ubuntu) "With Mir enabled: maliit-server crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,Confirmed] | 12:04 |
| ogra_ | can someone tell me where Mir gets the VSYNC info from ? | 12:04 |
| asac | alf_: there is maliit and unity8 crash | 12:05 |
| asac | alf_: you say that unity8 crash goes away if maliit doesnt crash? | 12:05 |
| mlankhorst | bleh stupid thing, glClear being ignored;S | 12:05 |
| asac | alf_: _usr_bin_unity8.32011.crash | 12:05 |
| alf_ | asac: I am not saying anything :) | 12:05 |
| asac | hehe | 12:05 |
| * ogra_ is fiddling with bug 1234743 and moving the VSYNC event from a uevent to a sysfs node makes Mir choke while surfaceflinger still starts | 12:05 | |
| ubot5 | bug 1234743 in linux (Ubuntu) "omapfb module floods system with udev events on samsung galaxy nexus" [Undecided,Incomplete] https://launchpad.net/bugs/1234743 | 12:05 |
| asac | well, you said its in progress most likely... but that smells like the maliit fix | 12:05 |
| asac | not the unity8 | 12:05 |
| asac | alf_: the unity8 goes away on SF as well | 12:05 |
| asac | i wouls suggest embracing that as a crash that is caused by MIR interactions | 12:06 |
| === alan_g is now known as alan_g|lunch | ||
| mlankhorst | oh you've got to be kidding me | 12:07 |
| alf_ | asac: not how I diplomatically said that *most* of the crashes... have been fixed ;) | 12:09 |
| alf_ | asac: s/not/note/ | 12:09 |
| asac | right | 12:09 |
| asac | are you on this one? | 12:09 |
| alf_ | asac: I am now | 12:09 |
| asac | any leads/hopes? | 12:09 |
| asac | nice :) | 12:09 |
| alf_ | mlankhorst: ? | 12:19 |
| mlankhorst | nah was hoping for a more logical explanation, meh | 12:25 |
| mlankhorst | I'll try without radeon, and use intel, at least it has dri2 support. :P | 12:26 |
| === hikiko|lunch is now known as hikiko | ||
| === alan_g|lunch is now known as alan_g | ||
| mlankhorst | alf_: but that code was working with android right? | 13:00 |
| alf_ | mlankhorst: yes | 13:00 |
| mlankhorst | alf_: only thing i found so far is that linuxvirtualterminal should probably not be created in nested, meh | 13:46 |
| alf_ | tvoss: What's the problem in maliit with bug 1233988? I have found a problem in platform-api related to this, too... | 14:07 |
| ubot5 | bug 1233988 in maliit-framework (Ubuntu) "With Mir enabled: maliit-server crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,Fix committed] https://launchpad.net/bugs/1233988 | 14:07 |
| alf_ | lool: ^^ | 14:07 |
| alan_g | alf_: tvoss is exploring the theory that because we've not linked the Mir client library against pthreads maliit blows up. (I don't know if the theory has been tested yet) | 14:11 |
| tvoss | alan_g, issue is solved, it wasn't that in the end | 14:14 |
| tvoss | alan_g, but: -pthread is still a good idea | 14:14 |
| alan_g | tvoss: then what was it? | 14:15 |
| tvoss | alan_g, maliit trying to access mir, without mir running :) | 14:16 |
| tvoss | alan_g, working on a fix to the platform api | 14:16 |
| tvoss | alan_g, it should handle that situation more graceful | 14:16 |
| alan_g | tvoss: "mir running" == there's a Mir connection? | 14:17 |
| alf_ | tvoss: lool: alan_g: see my latest comment and MP in https://launchpad.net/bugs/1233988 | 14:18 |
| ubot5 | Ubuntu bug 1233988 in platform-api (Ubuntu) "With Mir enabled: maliit-server crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,In progress] | 14:18 |
| mlankhorst | alf_: meh I'll try what happens if I always enable gbm, ran out of other ideas :P | 14:21 |
| alan_g | alf_: tvoss I see. But Mir is also behaving badly - it ought to fail operations, not crash. (One reason for returning an "Error" connection is that it can provide sensible error mode behaviour) | 14:21 |
| alf_ | alan_g: agreed | 14:22 |
| tvoss | alan_g, true. I won't find time to fix that part, though | 14:22 |
| === alan_g is now known as alan_g|tea | ||
| === pete-woods is now known as pete-woods-away | ||
| mlankhorst | alf_: ah excellent, if I force the gbm path to be always taken it corrupts too, that makes it a lot easier to debug.. | 14:31 |
| mlankhorst | http://paste.debian.net/55230/ | 14:32 |
| mlankhorst | to the best of my knowledge, it should behave identically right? | 14:33 |
| === ricmm_ is now known as ricmm | ||
| === alan_g|tea is now known as alan_g | ||
| alf_ | mlankhorst: when you have some time please check https://code.launchpad.net/~hikiko/mir/mir.fix-in-session-leader/+merge/190353 (also see my comment there) | 14:57 |
| asac | alf_: did your crash investigation give reason for hope :)? | 14:58 |
| alf_ | asac: got caught up in https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1233988, wanted to fix the strange crash to ensure it's not involved somehow with the ap failures/maliit | 15:01 |
| ubot5 | Ubuntu bug 1233988 in platform-api (Ubuntu) "With Mir enabled: maliit-server crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,In progress] | 15:01 |
| alf_ | asac: so no direct progress there yet | 15:01 |
| racarr | good mirning | 15:06 |
| hikiko | alf_, I replied just now | 15:06 |
| kgunn | racarr: mornin' | 15:18 |
| lool | alf_: looking | 15:29 |
| lool | alf_: platform-api change to detect whether connection is truly good seems a good idea | 15:31 |
| lool | alf_: but I'd rather not confirm the exact semantics of the functions you're calling etc. | 15:32 |
| lool | alf_: would someone else review this? then we can add this to landing plan | 15:32 |
| racarr | trying out new image :) | 15:33 |
| alf_ | racarr: want to review https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-somewhat/+merge/190378 ? :) | 15:34 |
| tvoss | alf_, did you remove the anon namespace in the header file? :) | 15:34 |
| racarr | alf_: only somewhat happy :p | 15:35 |
| racarr | alf_: +1 | 15:37 |
| alf_ | racarr: thanks | 15:37 |
| racarr | image seems really good | 15:37 |
| === pete-woods-away is now known as pete-woods | ||
| racarr | I'd really like to fix the | 15:37 |
| racarr | screen unblank buffer | 15:37 |
| racarr | bla | 15:37 |
| racarr | actually now | 15:38 |
| alf_ | tvoss: no, why? | 15:38 |
| asac | any luck on unity8 crashers? :) | 15:38 |
| asac | lol | 15:38 |
| racarr | asac: Autopilot you mean? | 15:38 |
| asac | unity8 crashes | 15:39 |
| asac | during autopilot its easy to reproduce yes | 15:39 |
| asac | just run webbrowser AP | 15:39 |
| asac | and it will crash | 15:39 |
| asac | 5 out of 6 times | 15:39 |
| racarr | ok I guess I can work on autopilot failures today | 15:39 |
| tvoss | alf_, an anonymous namespace in a header file is usually a bad idea | 15:40 |
| asac | racarr: note that its not really autopilot failures... its just the best and easiest to reproduce crashers we have right now :) | 15:40 |
| asac | we see loads of crashers that are hard to reproduce in QA | 15:40 |
| asac | so we can start here and hopefully the world will improve :) | 15:40 |
| racarr | asac: :D | 15:41 |
| asac | anyway. let me know ifyou need something | 15:41 |
| asac | those are real crashers ... we dont start unity with special instrumentation flags or anythig | 15:41 |
| asac | if we run application autopilots | 15:41 |
| asac | thanks! | 15:42 |
| alf_ | tvoss: sure, "why" == is it related to the 1233988 problem in some way? | 15:42 |
| tvoss | alf_, nope | 15:43 |
| alf_ | racarr: btw, keep in mind that running the tests one by one seems to work just fine, which give a hint to what the problem is... | 15:43 |
| alf_ | tvoss: ok :) | 15:43 |
| asac | alf_: you talk about webbrowser? | 15:44 |
| asac | there are two things: | 15:44 |
| asac | a) webbrowser tests fail and make unity super slow after they finish | 15:44 |
| lool | racarr: didn't top approve? | 15:44 |
| asac | b) webbrowser tests crash unity8 more or less relliably | 15:44 |
| racarr | asac: I...lost the bug that someone put autopilot instructions in. Is there a summary somewhere? | 15:44 |
| lool | ah right, two reviews I guess | 15:44 |
| lool | alf_: so once that's top approved ping me to get it in PPA for testing | 15:45 |
| racarr | lool: Hmm no someone could top approve I guess | 15:45 |
| asac | racarr: https://wiki.ubuntu.com/Touch/Testing#Testing_your_Ubuntu_Touch_Code_before_submission | 15:45 |
| asac | give that a shot | 15:45 |
| kgunn | racarr: for running AP tests run 'phablet-click-test-setup' to download all the test cases | 15:45 |
| kgunn | 'phablet-test-run <suite>'...e.g. unity8 | 15:45 |
| lool | to run tests: | 15:45 |
| alf_ | racarr: apt-get install webbrowser-app-autopilot, autopilot run <test> | 15:45 |
| lool | a) touch /userdata/.writable_image | 15:45 |
| asac | alf_: dont do that | 15:45 |
| lool | b) reboot | 15:45 |
| racarr | tvoss: Want to double sanity check the papi branch and top approve? | 15:45 |
| lool | c) unlock screen | 15:45 |
| asac | alf_: use the isntructions above | 15:45 |
| lool | then run: | 15:45 |
| lool | ./phablet-test-run -p webbrowser-app-autopilot webbrowser_app | 15:45 |
| lool | or for unity8: | 15:46 |
| tvoss | racarr, feel free | 15:46 |
| lool | ./phablet-test-run -n -p unity8-autopilot unity8 | 15:46 |
| asac | otherwise we will argue until we are blue about not seeing the same things | 15:46 |
| alf_ | asac: why not? | 15:46 |
| lool | alf_: use the phablet-test-run interface | 15:46 |
| asac | alf_: doesnt matter... just strictly follow the instructionms | 15:46 |
| lool | alf_: so that we all do the same thing | 15:46 |
| asac | alf_: people dont get it right and do stuff to their device | 15:46 |
| racarr | *parsing* XD thanks all | 15:46 |
| asac | and then claim the tests succeed and move on | 15:46 |
| ogra_ | make sure to reboot after the unity8 tests ... never run an app test after unity | 15:46 |
| asac | and i have to argue for 2 days with them until they finally see that they didnt do it the same way | 15:47 |
| asac | lool: please refer to these isntructions: https://wiki.ubuntu.com/Touch/Testing#Testing_your_Ubuntu_Touch_Code_before_submission | 15:47 |
| kgunn | racarr: what do you need top approved ? | 15:47 |
| asac | so we start consolidating it at one place | 15:47 |
| racarr | kgunn: https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-somewhat/+merge/190378 I did it though | 15:47 |
| kgunn | lool: can we get a CI run & landing on https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-somewhat/+merge/190378 | 15:48 |
| tvoss | kdub, ping | 15:49 |
| kdub | hello | 15:50 |
| kgunn | Saviq: just to make sure we don't have people running round duplicating effort.... racarr is going to look into crashes associated with webbrowser AP tests | 15:50 |
| kgunn | shout if someones already working | 15:50 |
| kdub | tvoss, going to try to shift waiting to the compositor side, should make unity wait less | 15:51 |
| lool | kgunn: autolanding actually -- ci ran | 15:51 |
| tvoss | kdub, sounds good, had the same idea. | 15:51 |
| kdub | tvoss, i'll let you know once i've tested it... just getting my phone all put together | 15:51 |
| lool | kgunn: was waiting for the top approve :-) | 15:51 |
| tvoss | kdub, I will grab a quick bite and be back after that | 15:51 |
| mlankhorst | argh I don't see why this should give different results.. | 15:52 |
| kgunn | lool: so we are back to normal everywhere ? (no more manual merges) | 15:52 |
| Saviq | kgunn, tvoss, racarr, maliit loops on unity8 exit with https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1238107 | 15:52 |
| ubot5 | Ubuntu bug 1238107 in maliit-framework (Ubuntu) "maliit-server crashed with SIGSEGV in poll()" [Undecided,New] | 15:52 |
| lool | kgunn: running | 15:52 |
| Saviq | tvoss, I saw the copy_on_client DisplayConfiguration somewhere before | 15:52 |
| Saviq | tvoss, today, that is | 15:52 |
| lool | kgunn: Only on some projects; Francis sent a list; I dont know for yours, but you sometimes have to wait 15mn for a run, so pinging might still be useful when urgent | 15:53 |
| kgunn | ack | 15:53 |
| lool | asac: I've updated the AP instructions with my own additions for other testsuites and for Click instructions | 15:53 |
| tvoss | Saviq, something went out of scope too early | 15:53 |
| tvoss | Saviq, racarr the DisplayConfiguration is NULL | 15:54 |
| Saviq | tvoss, I expect unity8 hanging at the same time to be very much related, correct? | 15:55 |
| alf_ | Saviq: copy_on_client problem, essentially means that the connection to the server failed for some reason (no server, connection rejected), and platform-api wasn't handling this well, see https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-somewhat/+merge/190378 | 15:55 |
| Saviq | alf_, yay, so that's fixed | 15:55 |
| Saviq | alf_, I knew I saw that somewhere | 15:55 |
| racarr | Does mthis looks like | 15:55 |
| racarr | ... | 15:55 |
| racarr | what alf said | 15:55 |
| Saviq | alf_, racarr yes, it does | 15:55 |
| racarr | the mutex is null which can only happen if the mirconnection pointer | 15:55 |
| Saviq | yay, sorted | 15:56 |
| racarr | is invalid | 15:56 |
| tvoss | Saviq, not entirely sure, could be | 15:56 |
| * Saviq pushes unity8's crash on exit | 15:56 | |
| asac | lool: yeah. all this know how should be somewhere in phablet-tools i believe | 15:56 |
| asac | lool: would be great if phablet-test-run unity8-autopilot would just do the rigth thing | 15:56 |
| asac | :) | 15:56 |
| alf_ | Saviq: note, that's this only explains crashes for new connection attempts. If you see this for an existing connection then it's something else. | 15:57 |
| Saviq | alf_, ah, that's on unity8 exit | 15:59 |
| Saviq | alf_, so unity8 + maliit were connected, but unity8 was shutting down, pushed maliit over the edge into spinning, unity8 stuck | 15:59 |
| racarr | So what is expected to happen with the webbrowser ap tests? | 16:01 |
| racarr | I dont see a unity8 crash | 16:01 |
| racarr | but eventually the tests themselves crash... File "/usr/lib/python2.7/socket.py", line 303, in flush | 16:02 |
| racarr | self._sock.sendall(view[write_offset:write_offset+buffer_size]) | 16:02 |
| racarr | error: [Errno 32] Broken pipe | 16:02 |
| tvoss | asac, ^ | 16:03 |
| racarr | though it seems like they are still running lol because stuff is still going on on my phone | 16:03 |
| asac | racarr: what device are you on? | 16:03 |
| Saviq | tvoss, that looks like a Qt bug https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1238116 | 16:03 |
| ubot5 | Ubuntu bug 1238116 in unity8 (Ubuntu) "unity8 crashed with SIGSEGV in QIcon::~QIcon()" [Undecided,New] | 16:03 |
| racarr | asac: mako | 16:03 |
| Saviq | tvoss, unity8 crashes shutting down on Mir | 16:04 |
| tvoss | Saviq, hang on | 16:04 |
| Saviq | tvoss, hanging | 16:04 |
| asac | racarr: so not sure. you might be struck by something flaki :) | 16:04 |
| asac | lol | 16:04 |
| asac | so sometimes MTP is funny and takes over adb and you disconnect | 16:05 |
| asac | in those cases, just reboot and try again | 16:05 |
| asac | it doesnt happen all of the times :) ... wait until you have MTP seen mounted i guess | 16:05 |
| racarr | mm | 16:05 |
| racarr | going to try unity8 next... | 16:06 |
| racarr | I have to run soon though, one more dental filling :( (they couldn't quit finish last time) | 16:06 |
| racarr | ill be back before too long though | 16:06 |
| alan_g | alf_: I think your issues with this are addressed? https://code.launchpad.net/~robertcarr/mir/socket-messenger-race/+merge/187647 | 16:06 |
| lool | tvoss: I tested adding a rm to unity8 upstart job; then unity8 crashed and when I used it again, the keyboard would show up when entering an input field, but its window would disappear each type I type letter | 16:09 |
| lool | tvoss: so I think it was still using the old socket | 16:09 |
| tvoss | lool, do you have both pre start and post stop? | 16:10 |
| tvoss | Saviq, looking at it, need to debug | 16:12 |
| tvoss | Saviq, what did you do? | 16:12 |
| tvoss | Saviq, gut feeling tells me: qt | 16:12 |
| lool | tvoss: no | 16:13 |
| lool | tvoss: also didn't check whether maliit indeed restarted | 16:13 |
| Saviq | tvoss, that's just unity8 exiting | 16:13 |
| lool | tvoss: I'm running out of time for today | 16:13 |
| Saviq | tvoss, 100% reproducible | 16:13 |
| racarr | got unity8 autopilot running at least. um | 16:13 |
| tvoss | lool, sure, no problem ... got your current pushed to a branch? | 16:13 |
| racarr | some tests seem to be running | 16:13 |
| lool | need to get some sleep tonight, might not be able to test this further today | 16:13 |
| Saviq | tvoss, let me see if another one will be the same trace | 16:13 |
| tvoss | Saviq, ack | 16:14 |
| racarr | its a little confusing XD. | 16:14 |
| racarr | will dig deepeer on crashes when I get back | 16:14 |
| Saviq | racarr, they're all running, more or less | 16:15 |
| Saviq | racarr, but only the first one in a run gets input | 16:16 |
| ogra_ | lool, tvoss https://code.launchpad.net/~mterry/session-manager-touch/socket/+merge/186391 | 16:16 |
| ogra_ | not sure if that helps anything | 16:16 |
| ogra_ | (i had it on my MP monitoring list) | 16:16 |
| Saviq | racarr, maybe you'd have an idea about that? or could help tracking it down? | 16:19 |
| Saviq | racarr, if you run two or more unity8 tests within one autopilot run, only the first one will get input | 16:19 |
| lool | ogra_: I commented on the branch | 16:24 |
| alf_ | alan_g: yes, approved | 16:24 |
| lool | tvoss: did you send the -pthread thing to trunk? | 16:27 |
| tvoss | lool, nope | 16:27 |
| lool | tvoss: we have a slot for it FYI | 16:27 |
| tvoss | lool, ah okay ... | 16:27 |
| tvoss | there was some discussion on the mp | 16:27 |
| lool | looking | 16:28 |
| lool | tvoss: I miss the devel mp? | 16:28 |
| lool | tvoss: only have the trunk one | 16:28 |
| lool | tvoss: In any case -lpthread is wrong and should be fixed to -pthread | 16:29 |
| lool | even if it didn't fix whatever we were seeing | 16:29 |
| lool | tvoss: this is how I had changed unity8.conf upstart job: http://paste.ubuntu.com/6218716/ | 16:29 |
| tvoss | lool, hang on | 16:30 |
| tvoss | lool, https://code.launchpad.net/~thomas-voss/mir/add-pthread-linker-and-preprocessor-flags/+merge/190316 | 16:31 |
| lool | thanks | 16:31 |
| tvoss | alan_g, removed the linked bugs | 16:31 |
| lool | will add to tracking | 16:31 |
| lool | tvoss: oh that's against trunk again | 16:31 |
| lool | isn't it? | 16:31 |
| lool | tvoss: that's the one I had | 16:32 |
| tvoss | lool, yup, that's against trunk, want me to resubmit against devel? | 16:32 |
| lool | tvoss: Just send it against devel branch? | 16:32 |
| lool | tvoss: I think that's mir process | 16:32 |
| lool | tvoss: first land in devel, then merge devel in trunk | 16:32 |
| lool | tvoss: but others here are more knowledgeable on this | 16:32 |
| alan_g | tvoss: yes | 16:33 |
| === dandrader is now known as dandrader|lunch | ||
| alan_g | lool: " | 16:33 |
| alan_g | lool: @"In any case -lpthread is wrong and should be fixed to -pthread" - comment against the MP. chat gets lost | 16:34 |
| tvoss | alan_g, lool resubmitted | 16:34 |
| alan_g | tvoss: spurious changes: debian/changelog | 16:39 |
| === yofel_ is now known as yofel | ||
| om26er | kdub, btw if you need any help testing something. I am at service | 16:43 |
| kdub | thanks om26er | 16:43 |
| mlankhorst | alf_: but the diff I posted is the smallest way to reproduce the problem, if you apply it it happens with normal mir clients too and not just nested :P | 16:46 |
| mlankhorst | and I have no explanation as to why | 16:49 |
| === ChickenCutlass is now known as ChickenCutlass_l | ||
| pete-woods | but I'll keep looking | 16:58 |
| === alan_g is now known as alan_g|EOD | ||
| jono | really nice job on Mir on the N4 :-) | 17:05 |
| jono | working pretty good for me :-) | 17:05 |
| === chihchun_afk is now known as chihchun | ||
| ogra_ | jono, just because your last name isnt -autopilot | 17:16 |
| ogra_ | ther test results are still pretty bad (but we're getting there) | 17:16 |
| tvoss | lool, alan_g|EOD https://code.launchpad.net/~thomas-voss/mir/add-pthread-linker-and-preprocessor-flags-2/+merge/190432 | 17:20 |
| lool | tvoss: approved but not top approved; leaving that to mir folks | 17:21 |
| tvoss | lool, ack, sorry, took me a while, my bzr foo was lacking | 17:21 |
| lool | tvoss: np, added to landing plan too, but will need this to go to trunk too | 17:22 |
| lool | alf_: You might have expected me to test your branch; I just made sure it went to PPA and someone else will try it in landing plan; might be good to provide some instructions on testing it | 17:23 |
| lool | alf_: sorry, not staying long tonight, otherwise would have tried it out | 17:23 |
| * lool off & | 17:23 | |
| tvoss | lool.sleep() | 17:27 |
| tvoss | lool.force_to_sleep(); | 17:27 |
| tvoss | lool, awesome job, dude | 17:27 |
| jono | ogra_, yeah, seems like a good integration result | 17:32 |
| jono | and now everyone can focus on bugfixing | 17:33 |
| ogra_ | well, first on getting the tests to work again | 17:33 |
| ogra_ | then on bugfixing | 17:33 |
| jono | :-) | 17:35 |
| racarr | Back | 18:07 |
| ogra_ | Front | 18:10 |
| === dandrader|lunch is now known as dandrader | ||
| === ChickenCutlass_l is now known as ChickenCutlass | ||
| racarr | :p | 18:19 |
| davmor2 | kgunn: or any one else. The logs in /home/phablet/.cache/upstart are they only for the current session? i.e. if I say pull the battery out to get back to a working system does it start the log afresh? | 18:34 |
| kgunn | davmor2: good question...i think it can be a mix....for unity i suspect new everytime...for things that maybe dont get autolaunched on boot, i suspect they're old | 18:35 |
| kgunn | davmor2: i say this because i see diff timestamps when i look | 18:35 |
| kgunn | just noticed earlier myself :) | 18:35 |
| davmor2 | kgunn: that'll possibly be why I can't see anything obvious for this lock up issue that maguro has then | 18:36 |
| davmor2 | kgunn: in order to get back to a working system to pull the logs I need to pull the battery | 18:37 |
| kgunn | davmor2: weird...so when it locks up, you can't even adb shell in ? | 18:38 |
| davmor2 | kgunn: Nope and macslow confirmed too | 18:38 |
| davmor2 | kgunn: the only thing you can do is pull the battery, even pressing and holding the power button does nothing | 18:39 |
| davmor2 | kgunn: thankfully it doesn't seem to be hitting mako's | 18:39 |
| davmor2 | kgunn: I also tried getting around it by running top in adb shell so the connection was live when it died, but that just kicks you out of the adb session when it locks up and you can't get back in | 18:41 |
| davmor2 | kgunn: I've been trying to get some reproducible steps, but there don't seem to be any. You can have lots of apps open, 1 app open, be swiping between scopes, or pulling down the indicator bar | 18:43 |
| kgunn | davmor2: mmmm....that actually sounds kernel-ish | 18:44 |
| davmor2 | kgunn: only happen on mir, on SF I could run it all day no hangs | 18:45 |
| tvoss | kdub, which buffers and how many do we hand out to internal clients? | 19:00 |
| kdub | tvoss, internal and external have the same type of buffers and same count | 19:01 |
| kdub | so, gpu buffers (not fb's or flagged for hwc usage) and 3 | 19:01 |
| tvoss | kdub, hmmm, why would the shell ever block then? | 19:02 |
| kdub | tvoss, my branch linked to that slowness bug helps the speed | 19:02 |
| kdub | i messed up something having to do with snapshotting in that branch though, have to figure out what | 19:03 |
| tvoss | kdub, mind pinging me the link? | 19:03 |
| kdub | https://code.launchpad.net/~kdub/mir/android-buffer-syncfence | 19:03 |
| tvoss | kdub, awesome | 19:04 |
| kgunn | i swear i think dash decelerates .... | 19:07 |
| kgunn | render times are pretty quick...then get large when you take your finger off | 19:07 |
| tvoss | kdub, I like what I see | 19:07 |
| tvoss | kdub, is the performance improvement tangible? | 19:08 |
| kgunn | woohoo go kdub | 19:08 |
| kdub | tvoss, haven't measured | 19:10 |
| kdub | trying to track down why when you click 'recent apps' you get a white snapshot frame in there in that branch atm | 19:11 |
| tvoss | kdub, ack | 19:11 |
| thomi | morning | 19:11 |
| tvoss | kdub, go ahead | 19:11 |
| racarr | morning thomi | 19:11 |
| thomi | o/ | 19:12 |
| tvoss | o/ | 19:12 |
| thomi | hey tvoss, up late? | 19:12 |
| tvoss | thomi, yup, as usual during this week | 19:12 |
| thomi | :( | 19:13 |
| tvoss | thomi, all good :) it's actually quite a lot of fun | 19:14 |
| thomi | I suppose. I've not been feeling well for the last couple of weeks - mostly I'm always tired. Can hardly keep my eyes open, even after my numerous coffees | 19:14 |
| tvoss | thomi, oh, sounds like you should go and see a doctor | 19:15 |
| tvoss | thomi, do you have enough water with your coffee? | 19:15 |
| thomi | tvoss: I would, but it's not that bad - I'm just tired, no other symptoms | 19:15 |
| thomi | tvoss: actually, that reminds | 19:15 |
| thomi | me | 19:15 |
| * thomi goes to find his water bottle | 19:15 | |
| kgunn | kdub: that's freakin' awesome.... | 19:29 |
| kgunn | just tried your sample "make it go fast" | 19:30 |
| kdub | thanks :) | 19:30 |
| kgunn | kdub: you do realize when you do things like this people will just keep expecting miracles | 19:30 |
| tvoss | kdub, awesome !!! | 19:31 |
| kgunn | davmor2: you still on ? | 19:31 |
| davmor2 | kgunn: I am | 19:32 |
| kdub | :D | 19:32 |
| kgunn | davmor2: wanna try something on maguro ? | 19:32 |
| davmor2 | kgunn: just doing a flash at the minute but I'm happy to try after | 19:32 |
| * kdub doesnt know if that will fix maguro | 19:32 | |
| tvoss | kdub, no worries, we will try ;) | 19:32 |
| davmor2 | kdub: I'm as happy to break your code as anyone elses I wouldn't want you to fell left out :) | 19:33 |
| kgunn | kdub: mmm....it should be indep of hwc1.0 vs 1.1 right ? | 19:33 |
| tvoss | kgunn, screw it, let's just try | 19:34 |
| tvoss | :) | 19:34 |
| kdub | well, i think the omap drivers are using the deprecated native window hooks, which don't do anything with fencing | 19:34 |
| kgunn | yeah...omap efforts pre-dated the butter activity | 19:35 |
| kgunn | kdub: so just to confirm...i was taking data just before copying over your fix | 19:42 |
| kgunn | kdub: and the qml render numbers are back down to where they were weeks ago | 19:42 |
| tvoss | \o/ | 19:42 |
| * tvoss goes to get alcohol | 19:43 | |
| kgunn | kdub: like...roughly ~27ms todays image....copy your *.so's....i'm getting ~8ms | 19:43 |
| ricmm | yea | 19:43 |
| ricmm | renders are back to near-SF numbers | 19:43 |
| ricmm | swap time went down in half too | 19:44 |
| ricmm | all we need is screenshots now | 19:44 |
| kgunn | kdub: a few spikes of 19/20 ms....but not completely abnormal....plus I am certain...unity/qt does something funky to decelerate | 19:44 |
| kgunn | when you lift a finger or come to a stop | 19:44 |
| kgunn | kdub: not only that....i'm convinced the quality is actually better than SF...since they had some serious flickering you could easily witness | 19:45 |
| kgunn | kdub: btw, i do not see the white full screen render...did you already fix that pre-herion sample | 19:46 |
| ricmm | the white frames are when tapping on a running app | 19:47 |
| ricmm | the screenshot should slide in from the right | 19:47 |
| ricmm | however it is an empty frame thats doing it | 19:47 |
| kgunn | ricmm: btw...i didn't try your powerd deb yet...i was having trouble getting the latest image to exhibit the "can't unblank" upon a unity8 stop/start | 19:49 |
| kgunn | i wanted to ensure i could easily repro the problem.... | 19:49 |
| kgunn | i did just get one...but had been doing this many times | 19:50 |
| kgunn | ricmm: do you still want me to try that deb ? | 19:50 |
| ricmm | what deb? | 19:54 |
| ricmm | the powerd one? | 19:54 |
| ricmm | they are already testing it for tests | 19:54 |
| ricmm | kdub: so I see a difference now with screenshots | 19:55 |
| kgunn | ricmm: yeah...ok.... | 19:55 |
| ricmm | kdub: less screenshotting issues, before most of the times the surface wouldnt be ready for screenshotting | 19:55 |
| ricmm | so it would use an old screenshot instead of refreshing | 19:55 |
| ricmm | kdub: now with this patch the surface is allowing the screenshot | 19:56 |
| ricmm | which is actually making it lag behind a bit while its mapped to sheet coming in from the right | 19:56 |
| ricmm | kdub: tvoss kgunn worse comes to worse I prefer this over the choppiness | 19:57 |
| ricmm | I can live with a couple frames of white | 19:57 |
| tvoss | ricmm, +1 | 20:00 |
| tvoss | ricmm, kdub http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/92:20131010.2:20131010/4662/ | 20:01 |
| ricmm | not bad | 20:02 |
| racarr | I am going to work on this...extra characters showing up from real keyboards/autopilot keyboard http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/92:20131010.2:20131010/4662/calendar-app-autopilot/474291/ | 20:02 |
| kdub | yeah, getting better | 20:02 |
| racarr | should be pretty easy to isolate | 20:02 |
| racarr | and probably just a problem in qtubuntu or our xkbcommon mapper | 20:02 |
| ricmm | I've seen it happen in normal apps with OSK | 20:03 |
| ricmm | as soon as you bring up or focus a text field | 20:03 |
| ricmm | garbage char will be delivered | 20:03 |
| ricmm | once I had the filter branch for the hardware keys that didnt happen | 20:03 |
| racarr | ah I havent seen ti happen with osk I dont believe | 20:04 |
| racarr | ok. quick lunmch before an afternoon of digging autopilot failures | 20:11 |
| davmor2 | kgunn: it's feels faster initially, however it is also glitchier here. So for example I opened to the camera app and there was lots of flashing that wasn't there before, if you tap on the flash for example. I'll have a proper go at it after I log off in a bit and I'll double check that I have put files in the right places too | 20:17 |
| davmor2 | I'll let you know tomorrow ;) | 20:19 |
| davmor2 | night all | 20:19 |
| kgunn | davmor2: cool... | 20:21 |
| kgunn | davmor2: yeah...mainly curious about the dash app lens full of icons scrolling | 20:22 |
| === bschaefer_ is now known as bschaefer | ||
| racarr | Back | 21:02 |
| rsalveti | hey, need help with mir specific crash | 21:03 |
| rsalveti | getting the following after linking to ubuntu_application_api_mirclient | 21:04 |
| rsalveti | gst-codec-info loads libandroidmedia, which depends on libubuntu_application_api_mirclient, probe for video caps, and then crashes when trying to unload the library | 21:04 |
| rsalveti | not using any platform-api or mir specific call at this point | 21:04 |
| rsalveti | http://paste.ubuntu.com/6219717/ | 21:04 |
| rsalveti | the crash | 21:04 |
| rsalveti | ricmm: racarr: ^ | 21:06 |
| racarr | rsalveti: I am thinking | 21:07 |
| racarr | rsalveti: So, static deinitialization segfault is almost certainlly | 21:07 |
| racarr | some sort of linking error | 21:07 |
| racarr | so the first thought is | 21:07 |
| racarr | https://code.launchpad.net/~thomas-voss/mir/add-pthread-linker-and-preprocessor-flags-2/+merge/190432 | 21:08 |
| racarr | but I don't know exactly how | 21:08 |
| racarr | that would produce this | 21:08 |
| rsalveti | racarr: would that branch help? | 21:09 |
| rsalveti | tvoss: ^ | 21:09 |
| rsalveti | not sure how would be related | 21:09 |
| rsalveti | wonder why this wasn't causing any issue before we tried this | 21:10 |
| tvoss | rsalveti, nope, looks like something different | 21:10 |
| rsalveti | same code was working fine when linking against ubuntu_application_api | 21:11 |
| rsalveti | as all it's doing at this point is loading & unloading it | 21:11 |
| tvoss | rsalveti, my brain is fried tbh :/ | 21:11 |
| rsalveti | seems a common issue around here this week lol | 21:11 |
| racarr | rsalveti: I dunno...I would ldd things and look for any conflicts but I am not sure...what could show up | 21:14 |
| === jhodapp is now known as jhodapp|bbiab | ||
| rsalveti | racarr: ldd seems sane http://paste.ubuntu.com/6219825/ | 21:19 |
| racarr | rsalveti: Mm | 21:20 |
| racarr | maybe valgrind or something | 21:20 |
| racarr | can give hints | 21:20 |
| racarr | at earlier corruption | 21:20 |
| racarr | rsalveti: There may be interesting stuff with LD_DEBUG=all (don't know LD_DEBUG well enough to suggest better flags) | 21:21 |
| racarr | It seems liek its probably either some sort of linking problem or | 21:21 |
| racarr | some sort of memory corruption | 21:21 |
| rsalveti | let me check | 21:21 |
| rsalveti | racarr: not much with valgrind: http://paste.ubuntu.com/6219845/ | 21:25 |
| rsalveti | checking linker | 21:25 |
| ChickenCutlass | rsalveti: is there any static init going on that might be failing | 21:26 |
| rsalveti | ChickenCutlass: we're not doing that in this lib directly | 21:26 |
| rsalveti | at this point we're just linking at it | 21:26 |
| ChickenCutlass | rsalveti: so linked at compile time with -l | 21:26 |
| rsalveti | the code that uses platform-api: https://github.com/jhodapp/gst-plugins-bad/blob/master/sys/androidmedia/gstamchybris.c | 21:27 |
| ricmm | rsalveti: wheres the code that does it | 21:27 |
| ricmm | ok | 21:27 |
| rsalveti | and how we're linking to it: https://github.com/jhodapp/gst-plugins-bad/blob/master/sys/androidmedia/Makefile.am | 21:27 |
| ricmm | and this isnt being used? | 21:28 |
| ricmm | why do you say its only loading and unloading | 21:28 |
| rsalveti | ricmm: nops, because gst-codec-info loads the lib, calls a function to get caps and close itself | 21:28 |
| rsalveti | ricmm: at this point nothing is calling platform-api | 21:28 |
| rsalveti | ricmm: I know because even when using mir, and calling with the older library, it works just fine | 21:29 |
| ricmm | do you have a bt ? | 21:31 |
| rsalveti | http://paste.ubuntu.com/6219870/ the build log | 21:31 |
| rsalveti | ricmm: bt? | 21:32 |
| rsalveti | ricmm: http://paste.ubuntu.com/6219717/ | 21:32 |
| ricmm | what the hell | 21:35 |
| racarr | rsalveti: Can you try the log from running it | 21:35 |
| racarr | with LD_DEBUG | 21:35 |
| rsalveti | racarr: uploading, but nothing really useful it seems | 21:36 |
| rsalveti | 37mb of logs | 21:36 |
| ChickenCutlass | rsalveti: could this be a missing hybrid hook? | 21:37 |
| ChickenCutlass | rsalveti: sure looks like it | 21:37 |
| ChickenCutlass | hybris | 21:37 |
| ChickenCutlass | but why? | 21:37 |
| ChickenCutlass | on just loading the lib | 21:37 |
| racarr | rsalveti: >< | 21:38 |
| rsalveti | ChickenCutlass: it's not | 21:39 |
| rsalveti | ChickenCutlass: all gst is doing is calling plugin_init | 21:39 |
| rsalveti | even if I put a simple return FALSE right after that, it crashes | 21:39 |
| rsalveti | ChickenCutlass: and works fine with the old platform-api lib | 21:39 |
| rsalveti | this is a crash at the class destructor it seems | 21:39 |
| ricmm | yea but at which class | 21:40 |
| ricmm | if you arent creating anything fro mplatform-api in there | 21:40 |
| rsalveti | I'm not | 21:40 |
| ricmm | I dont get why there would be a mention to mir in those logs | 21:40 |
| ChickenCutlass | ricmm: are there any static init's in there | 21:42 |
| rsalveti | ricmm: commented out all the platform-api related function calls and it worked now | 21:45 |
| rsalveti | will get them back one by one | 21:45 |
| ricmm | thought you said it wasnt being used! | 21:46 |
| rsalveti | ricmm: it's not | 21:46 |
| ricmm | then why would commenting them out screw it? | 21:47 |
| ricmm | err fix it | 21:47 |
| rsalveti | ricmm: this is what I added back: http://paste.ubuntu.com/6219951/ | 21:52 |
| rsalveti | ricmm: and it's not called! | 21:52 |
| rsalveti | and it's already enough for the crash | 21:52 |
| ricmm | ok | 21:52 |
| ChickenCutlass | rsalveti: so should you not use sizeof (session) | 21:54 |
| ChickenCutlass | rsalveti: not *session | 21:54 |
| rsalveti | ChickenCutlass: ricmm: http://paste.ubuntu.com/6219958/ | 21:56 |
| rsalveti | this is already enough for the crash | 21:56 |
| rsalveti | phablet@ubuntu-phablet:/tmp/test$ gcc test.c -o test -lubuntu_application_api_mirclient | 21:56 |
| rsalveti | phablet@ubuntu-phablet:/tmp/test$ ./test | 21:56 |
| rsalveti | Testing | 21:56 |
| rsalveti | Segmentation fault (core dumped) | 21:56 |
| ChickenCutlass | rsalveti: ah ok -- so ricmm bug | 21:56 |
| ricmm | give me some minutes | 21:57 |
| rsalveti | racarr: ^ | 21:57 |
| sarnold | does argv ever get passed to execve(2)? argv[argc] is expected to be a NULL pointer, and there's no trailing ascii NUL after \n in the first array element | 21:58 |
| rsalveti | works fine on the desktop | 21:59 |
| ricmm | that test.c is not crashing for me | 22:00 |
| ricmm | phablet@ubuntu-phablet:~$ ldd ./test libubuntu_application_api_mirclient.so.1 => /usr/lib/arm-linux-gnueabihf/libubuntu_application_api_mirclient.so.1 (0x401da000) | 22:00 |
| ricmm | phablet@ubuntu-phablet:~$ ./test | 22:00 |
| ricmm | Testing | 22:00 |
| ricmm | phablet@ubuntu-phablet:~$ | 22:00 |
| rsalveti | ricmm: latest image and everything? | 22:01 |
| ricmm | always | 22:01 |
| rsalveti | this also crashed with jhodapp|bbiab | 22:01 |
| ricmm | are you sure your mirclient platform-api and your mir are not somehow out of sync? | 22:01 |
| rsalveti | ricmm: unless I got a partial update with apt, no | 22:02 |
| ricmm | im resetting all my versions to saucy for mir and platform-api | 22:02 |
| ricmm | to make sure we have the same | 22:02 |
| ricmm | as I'm pretty sure I had trunk mir | 22:03 |
| rsalveti | ricmm: you did build your own mir, right? | 22:04 |
| ricmm | yea | 22:04 |
| ricmm | for the other bug | 22:04 |
| ricmm | sec still installing | 22:04 |
| rsalveti | yeah, have latest of everything | 22:04 |
| rsalveti | just did apt-get update & upgrade | 22:04 |
| rsalveti | just reproduced with maguro | 22:05 |
| rsalveti | let me reflash it with latest | 22:05 |
| rsalveti | might be fixed in trunk then | 22:05 |
| === jhodapp|bbiab is now known as jhodapp | ||
| ricmm | uh yea it breaks | 22:06 |
| rsalveti | \o/ | 22:06 |
| ricmm | lemme push trunk again | 22:06 |
| rsalveti | ricmm: trunk of mir or platform-api? | 22:06 |
| ricmm | mir, I havent rebuilt platform-api | 22:06 |
| jhodapp | so there's some issue with a version of the mir platform-api then? | 22:06 |
| rsalveti | jhodapp: mir | 22:07 |
| jhodapp | ah | 22:07 |
| rsalveti | jhodapp: http://paste.ubuntu.com/6219958/ is already enough to get the crash | 22:07 |
| jhodapp | wow | 22:07 |
| rsalveti | yeah, bad stuff | 22:07 |
| jhodapp | that's basic | 22:07 |
| ricmm | yea with my local build it seems to be fine | 22:09 |
| ricmm | trunk mir | 22:09 |
| rsalveti | let me build mir from trunk | 22:10 |
| ricmm | but I dont see anything in trunk that would cause this... | 22:11 |
| RAOF | mlankhorst: I was poking at nested-gbm yesterday, but mostly finding out that I'd misbuilt mesa in some way and so the egl platform was crashing after _glapi_get_proc_address returned garbage for glFlush | 22:12 |
| mlankhorst | RAOF: oh did you see my pastebin from earlier? | 22:12 |
| mlankhorst | I can reproduce the garbage with a normal client if I force a gbm device to be created and use the screen from that | 22:12 |
| RAOF | mlankhorst: Hm, no. | 22:13 |
| ricmm | racarr: trunk has nothing special in it, however having built it from my machine with the cross-compile script and deployed to phone makes it not fail | 22:13 |
| ricmm | racarr: what the hell? | 22:13 |
| mlankhorst | so just the fact that gbm is used is messing things up | 22:14 |
| mlankhorst | and i have no idea how | 22:14 |
| racarr | ricmm: Thiiiinking | 22:14 |
| mlankhorst | to the best of my knowledge the paths appear to be identical, at least after the gbm proxying :s | 22:14 |
| RAOF | mlankhorst: Could you repost your pastebin? | 22:16 |
| mlankhorst | http://paste.debian.net/55230/ | 22:16 |
| rsalveti | ricmm: does it fail if built natively? | 22:17 |
| rsalveti | well, it's a different toolchain | 22:17 |
| rsalveti | I'm building mir trunk locally to see | 22:17 |
| mlankhorst | RAOF: with that patch normal mir clients fail too, that should at least make it easier to debug :P | 22:18 |
| racarr | Does this just mean we broke client ABI somehow? | 22:18 |
| racarr | err no that doesn't quite make sense... | 22:18 |
| racarr | building trunk without rebuilding everything else reportedly fixes it | 22:18 |
| rsalveti | could be a toolchain/linker issue | 22:18 |
| racarr | maybe | 22:18 |
| rsalveti | well, ricmm cross-built it | 22:19 |
| racarr | something happened in say... | 22:19 |
| racarr | that introduces ABI breaks | 22:19 |
| racarr | err...in say hybris | 22:19 |
| racarr | or something else | 22:19 |
| racarr | and just mirclient | 22:19 |
| rsalveti | not a hybris issue | 22:19 |
| racarr | needed to be rebuilt against it | 22:19 |
| racarr | but wasn't | 22:19 |
| racarr | *shrug* it could be, if memory is getting stomped on in static initialization | 22:19 |
| rsalveti | rebuilding trunk locally ti see | 22:20 |
| Saviq | hey guys, here's another nice one... https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1238296 | 22:20 |
| ubot5 | Ubuntu bug 1238296 in maliit-framework (Ubuntu) "maliit-server crashed with SIGABRT in raise()" [Undecided,New] | 22:20 |
| ricmm | Saviq: thanks | 22:20 |
| Saviq | ricmm, /me got retracing powers now ;D | 22:21 |
| rsalveti | maybe similar issue? | 22:21 |
| rsalveti | no, looks different | 22:22 |
| ricmm | different trace | 22:22 |
| ricmm | racarr: rebuilt platform-api against my local build and it still works | 22:25 |
| ricmm | is it possible that something went wrong in the recent archive build? | 22:26 |
| rsalveti | ricmm: well, if rebuilding the current version fixes it, then it could | 22:29 |
| rsalveti | still waiting trunk here | 22:29 |
| racarr | I think if it does work, (rsalvetis build) | 22:36 |
| racarr | then probably Mir and <SOME PACKAGE> were buitl against different versions of <SOME PACKAGE> | 22:36 |
| racarr | err | 22:36 |
| racarr | <SOME OTHER PACKAGE> lol | 22:36 |
| ricmm | rsalveti: get that system76 already | 22:39 |
| ricmm | geez | 22:39 |
| rsalveti | ricmm: dude, building locally | 22:39 |
| rsalveti | == mako | 22:39 |
| ricmm | wow | 22:39 |
| ricmm | see you tomorrow then | 22:39 |
| racarr | rsalveti: Build from | 22:40 |
| racarr | build/src/ | 22:40 |
| racarr | and make install from there | 22:40 |
| racarr | skip tests | 22:40 |
| racarr | save lifetimes | 22:40 |
| rsalveti | ricmm: I need to confirm if this is not a toolchain issue | 22:40 |
| rsalveti | just build, will test now | 22:40 |
| rsalveti | ricmm: racarr: crashed still | 22:41 |
| rsalveti | just built and installed trunk | 22:41 |
| ricmm | well that sucks | 22:41 |
| ricmm | can you uh | 22:41 |
| ricmm | one sec | 22:41 |
| ricmm | merge lp:~kdub/mir/android-buffer-syncfence | 22:41 |
| ricmm | I know it makes no sense, but just try | 22:41 |
| ricmm | thats the only other change in my branch | 22:41 |
| rsalveti | sure | 22:42 |
| racarr | hmmm | 22:43 |
| rsalveti | shit, huge merge | 22:43 |
| ricmm | its pretty large yea but it shouldnt touch anything related to this | 22:43 |
| rsalveti | ricmm: replacing libmirclient.so is enough, right? | 22:45 |
| ricmm | should be as its talking about the connection | 22:45 |
| ricmm | but you never know with this beast | 22:45 |
| ricmm | replace it all | 22:45 |
| ricmm | as im doing so as well | 22:45 |
| rsalveti | yes sr | 22:46 |
| ricmm | im building a clean trunk, cross built | 22:46 |
| ricmm | I'll put the binaries up somewhere for you | 22:47 |
| ricmm | you put your locally built ones somewhere | 22:47 |
| rsalveti | ricmm: booom, no | 22:48 |
| ricmm | still failing? | 22:48 |
| ricmm | try http://people.canonical.com/~ricmm/mir-fixed/ | 22:48 |
| rsalveti | ricmm: where is the mir socket now? | 22:49 |
| rsalveti | trying to see if unity8 is still working | 22:49 |
| ricmm | I'm not sure, alan_g moved it | 22:49 |
| rsalveti | /run/user/32011/mir_socket | 22:49 |
| ricmm | right xdg runtime | 22:49 |
| rsalveti | ricmm: this shit is fast now | 22:50 |
| ricmm | super pro | 22:50 |
| rsalveti | ricmm: so yeah, using the right ones | 22:50 |
| rsalveti | let me try with yours | 22:50 |
| rsalveti | people.c is super slow for me today | 22:53 |
| rsalveti | I believe this issue might be happening with unit8 as well | 22:54 |
| rsalveti | it's crashing during shutdown | 22:54 |
| ricmm | sounds terribad | 22:55 |
| rsalveti | ricmm: no crash with yours | 22:55 |
| rsalveti | smells like toolchain | 22:55 |
| ricmm | well thats odd | 22:55 |
| rsalveti | let me open a bug | 22:55 |
| rsalveti | ricmm: bug 1238312 | 22:59 |
| ubot5 | bug 1238312 in Mir "Segfault when closing apps that link against ubuntu_application_api_mirclient" [Critical,Confirmed] https://launchpad.net/bugs/1238312 | 22:59 |
| rsalveti | ricmm: please add that it works with your lib, when cross-built | 22:59 |
| racarr | kdub: sync fence is fast :D | 23:01 |
| ricmm | done | 23:01 |
| racarr | tested it out | 23:01 |
| rsalveti | ricmm: how can I cross build mir? | 23:04 |
| ricmm | rsalveti: thres a script right in trunk | 23:04 |
| rsalveti | ricmm: want to cross build the same version used by the image | 23:04 |
| ricmm | ./cross-build-... | 23:04 |
| ricmm | something like that | 23:04 |
| rsalveti | great | 23:04 |
| kdub | racarr, yay | 23:05 |
| ricmm | * Authored by: Thomas Guest <thomas.guest@canonical.com> | 23:09 |
| ricmm | tvoss: is that you? lol | 23:09 |
| racarr | no | 23:10 |
| rsalveti | ricmm: creating phablet-compatible armhf partial chroot for mir compiles in directory /tmp/mir/mir-0.0.14+13.10.20131010/partial-armhf-chroot | 23:10 |
| rsalveti | E: No packages found | 23:10 |
| rsalveti | might be missing something still | 23:11 |
| ricmm | oh yea | 23:11 |
| ricmm | racarr: do you have the cross compile instructions list at hand? | 23:11 |
| ricmm | nvm | 23:11 |
| ricmm | rsalveti: http://unity.ubuntu.com/mir/building_source_for_android.html | 23:11 |
| ricmm | you need to add armhf sources to your apt | 23:11 |
| ricmm | its bad | 23:12 |
| rsalveti | haha, this is not for android | 23:12 |
| rsalveti | that's fine | 23:12 |
| ricmm | yea I dont know why its called that | 23:12 |
| rsalveti | this if for ubuntu dudes | 23:12 |
| racarr | at one point | 23:14 |
| racarr | it literally | 23:14 |
| racarr | was for android | 23:14 |
| racarr | in mirs case :p | 23:14 |
| rsalveti | right | 23:14 |
| rsalveti | not anymore :P | 23:14 |
| slangasek | rsalveti: :P | 23:18 |
| slangasek | rsalveti: can you reproduce this by linking directly to libmirclient? | 23:19 |
| rsalveti | one more :-) | 23:19 |
| rsalveti | trying, was just cross-building the same version to confirm | 23:19 |
| ricmm | rsalveti: soooo | 23:33 |
| ricmm | racarr: | 23:33 |
| ricmm | http://paste.ubuntu.com/6220225/ | 23:33 |
| ricmm | thats how it looks when it dies | 23:33 |
| ricmm | http://paste.ubuntu.com/6220219/ | 23:33 |
| ricmm | thats how it looks when it works | 23:34 |
| ricmm | the later hits the destructor of the hash table | 23:34 |
| ricmm | makes me believe that when it fails the hash table has bogus data and it attempts to clear the set | 23:35 |
| ricmm | which fails, probably guesses a wrong size | 23:35 |
| rsalveti | ricmm: slangasek: works fine when linking against libmirclient directly | 23:36 |
| rsalveti | but I know the platform-api one links to a bunch of mir related libs | 23:36 |
| ricmm | are you actually pointing to a function somewhere? | 23:36 |
| ricmm | if so, what mirclient func | 23:36 |
| rsalveti | ricmm: was trying mir_connection_is_valid, but checking if it's really part of that lib | 23:37 |
| rsalveti | src/client/mir_client_library.cpp:int mir_connection_is_valid(MirConnection * connection) | 23:38 |
| rsalveti | yup | 23:38 |
| rsalveti | ricmm: why is it trying to clear the hash table? | 23:40 |
| rsalveti | at that point, is it valid at all? | 23:40 |
| ricmm | it shouldnt be | 23:40 |
| ricmm | the compiler is generating different paths tho | 23:40 |
| ricmm | one is perhaps initializing it to null while the other is leaving it uninitialized, or something | 23:41 |
| ricmm | just guesses here | 23:41 |
| rsalveti | right | 23:41 |
| rsalveti | ricmm: slangasek: working with the cross-built based libs, same src version | 23:43 |
| ricmm | yea | 23:43 |
| ricmm | can you check cxflags? | 23:43 |
| ricmm | cxx | 23:43 |
| ricmm | perhaps there are some things different to the default way of building debs | 23:44 |
| rsalveti | probably | 23:44 |
| ricmm | optimization or other specific flags | 23:44 |
| rsalveti | ricmm: not sure because the cmake files are shared | 23:45 |
| === chihchun_afk is now known as chihchun | ||
| === jhodapp is now known as jhodapp|afk | ||
| rsalveti | ricmm: wonder why it seems to be fine If I link against it directly | 23:51 |
| rsalveti | maybe a different lib | 23:52 |
| rsalveti | linking against mir brings the entire universe | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!