robert_ancellkgunn, how did it go?00:07
kgunnrobert_ancell: thanks again...vt mir demo working00:11
kgunnaltho boot was still wonky00:11
kgunnlet me check logs00:11
kgunnok, symptom first...it hung first time in same way, striking keys like mad 2nd time...got it to boot00:14
kgunnso still jumped to vt800:14
kgunnbut here's the usc log -> https://pastebin.canonical.com/93337/00:15
kgunnat least it was quite diff this time00:15
kgunngotta run...getting yelled at00:16
RAOFOk, what the whatting what?01:16
RAOFduflu: Do you have any experience interposing libc symbols? Particularly: I want bin/unit-tests to wrap open()01:19
dufluRAOF: Yes, sadly01:20
RAOFOr, even more particularly, I want:01:20
RAOF        // If directly opening the DRM device is good enough for X it's good enough for us!01:20
RAOF        tmp_fd = open(dev_path, O_RDWR, O_CLOEXEC);01:20
dufluRAOF: Your new symbols need to be in a new SO01:20
RAOFto go through the mock.01:20
dufluRAOF: They need to be in a new SO, _and_ LD_PRELOAD'd if they're to override libc01:21
RAOFduflu: Really? Urgh. Looking at the LD_DEBUG=binding output, I see that libudev is binding open() to bin/unit-tests, and my open64 wrapper is getting called (by pthreads, apparently), but libmirserver.so.0 never binds open().01:22
dufluCos normally libc gets in before all your SOs01:22
dufluRAOF: The SO will use its own, but if you want process-wide wrapping then LD_PRELOAD01:22
RAOFI don't suppose -Wl,-z interpose would make this less painful?01:22
dufluHmm, could do01:23
dufluNot sure01:23
dufluRAOF: If it's not loaded early, properly, then you'll get some libraries using your version and some using libc's, which is bad01:23
dufluAnd don't forget to call the real open(), which you will find by dlsym(RTLD_NEXT, "open")01:25
RAOFMy wrapper works fine (as demonstrated by open64).01:25
dufluRAOF: We're lucky it's easy on Linux. When I did it in Windows I had to edit the binary instructions by hand at the start of each function :)01:28
RAOFThat sounds like much more fun!01:28
dufluWhich is not so easy on x86 because instructions vary in size. So you have to interpret them first.01:28
RAOFCouldn't you have just padded all your functions with enough noops to make that easier?01:31
RAOFAlso: boo. -z interpose is not teh win.01:32
RAOF !!!01:47
dufluRAOF: Not my functions. They were Microsoft's :)01:51
RAOFSo, my open() wrapper works, as evidenced by LD_PRELOADING it and gdb spitting out the debug spew I've made it emit.01:54
RAOFBut, for some reason, tmp_fd = open(dev_path, O_RDWR, O_CLOEXEC); is *not* wrapped.01:54
RAOFThat's not fair.01:58
RAOFIt's because that line is never called, because of an incorrect ‘!’ further up the function.01:59
nalltrying to make this work on VMWare still03:47
nallmir_demo_client_egltriangle ends on creating a shared ptr for GBMClientBufferFactory and then the server starts executing03:48
RAOFnall: It's not going to work in vmware at the moment; we require dma-buf support from the kms driver, and vmware does not have that support.03:48
nallK,gotcha.  Thanks03:49
RAOFWe do *want* to support vmware, and a fallback non-accelerated case if possible.03:50
RAOFIf you want to write code, there's code to be written :)03:50
nallYeah, I'm just trying to figure out where to start.03:51
nallI'd love to run Ubuntu natively on my machine but it's a company computer and the only one I've got.03:51
tvossgood morning :904:06
duflutvoss: Go back to bed you silly man04:08
dufluAnd good morning04:08
tvossduflu, :) all good, today is my early-bird day :)04:09
duflutvoss: Were you by any chance profiling Mir with 3 clients/surfaces? (like multiwin?)04:14
tvossduflu, nope, I started single client04:15
duflutvoss: Which one?04:15
tvossduflu, I think not even an egl one04:15
duflutvoss: Multiwin would create 3 surfaces, hence 18% I guess04:15
tvossduflu, ack04:15
tvossduflu, the shell/mobile guys were quite happy to hear about cpu optimizations, too04:16
dufluThough mathematically that does not scale accurately04:16
tvossduflu, yup :)04:16
duflutvoss: Yeah it's quite useful. Re-proposing just now04:16
tvossduflu, did my comment make sense?04:16
duflutvoss: Yes I added refs04:17
tvossduflu, great04:18
dufluAs usual, spent more time figuring out the gmock errors than making the change04:18
tvossduflu, for the glclear: How about having an interface ScreenClear that is given to the renderer? We could add a null implementation04:19
tvossoops, we made it slashdot :)04:19
duflutvoss: Yes you got slashdotted04:19
duflutvoss: Not sure which class, but the shell should be allowed to override the clear with anything04:19
duflutvoss: But then that may become generalized as I figure out a framework for transitions and animations (my main task)04:20
tvossduflu, ack, I just want to get rid of the glclear in a sane way on a short timescale04:21
duflutvoss: https://code.launchpad.net/~thomas-voss/mir/wait-for-vt-to-become-active-before-setting-mode/+merge/171099/comments/38149704:21
tvossduflu, not entirely sure, I was thinking about a test case, but hard to come up with one04:22
duflutvoss: There is no sane alternative to glClear until the shell renders a background of its own. And even then there's no benefit cos the wallpaper still takes up server CPU time04:23
dufluAlso, I think it was much less than 19% yesterday04:24
robert_ancellRAOF, where is the debian branch for the mesa build?04:24
RAOFrobert_ancell: In the ppa-somethingorother branch of github.04:24
tvossduflu, fair, but do we really need to clear in the mobile case? the shell will fill the entire display anyways04:25
tvossrobert_ancell, RAOF good morning :)04:25
RAOFtvoss: Good morning.04:26
robert_ancelltvoss,  very early morning to you04:26
tvossrobert_ancell, yup, my early bird day such that I can hug you guys :)04:26
RAOFtvoss: https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 is ready to roll, and should help us understand where sabdfl's laptop is failing04:26
tvossRAOF, great, let me give it a review04:27
tvossRAOF, sabdfl was hit by an Input/Output error while setting the mode on the vt, which made me look into the X code for setting up shared vt's -> VT_WAITACTIVE04:27
tvossRAOF, fails CI on amd6404:28
RAOFtvoss: Ah, it's just finished then.04:28
duflutvoss: The switching animation on mobile still shows black background, briefly, no?04:29
dufluAs the old surface moves away, it no longer fills the screen04:30
tvossduflu, nope :) that's faked, the shell always paints completely on top and just moves a screenshot of the surface around04:30
dufluHence you need a glClear before that04:30
duflutvoss: I mean when it's done properly. You still need a clear04:30
dufluMost frames... but not all04:30
tvossduflu, +1 :904:30
dufluI am trying to avoid any nasty occlusion calculations like compiz does04:31
dufluFor as long as possible04:31
dufluBut we'll need it for basic fullscreen testing04:31
RAOFtvoss: Boo. That doesn't happen locally, of course.04:32
tvossRAOF, a quick one at first glance: in class UdevHelper: mind making the ctx pointer private? or class -> struct if you only want value-semantics?04:33
RAOFIt's a failure to interpose the open() wrapper, which I *thought* I could get away with but it looks like duflu is annoyingly correct04:33
tvossrobert_ancell, welcome back :)04:33
robert_ancellsession crash :(04:33
RAOFtvoss: Sure. I04:33
dufluLD_PRELOAD FTW04:34
RAOFtvoss: As the comment mentions, it's going to want to grow into a fully-functional libudev wrapper.04:34
RAOFduflu: On *my* system LD_PRELOAD is unnecessary :(04:34
RAOFWhich is going to make testing the fix rather annoying.04:35
tvossRAOF, fair, but just make the class a struct then :)04:35
RAOFtvoss: Ok.04:35
tvosshmmm, how can we check if the kernel supports vt's at runtime? apart from randomly opening the actual vt?04:39
robert_ancelltvoss, I have wondered that myself04:39
tvoss_back :)04:41
* tvoss_ notes https://bugs.launchpad.net/mir/+bug/119421004:44
ubot5Launchpad bug 1194210 in Mir "XMir hang during google hangout on intel sandybridge" [Undecided,Incomplete]04:44
tvoss_RAOF, but I had those weird hangs w/o xmir, too04:44
tvoss_mhall119, ping04:44
tvoss_duflu, take it with a grain of salt: but why not leave away the const-qualifier on the transformation and get rid of the mutables? :)04:47
tvoss_I see your intention and it's a nice idea, but three members requiring mutable indicates that const might not be appropriate :)04:47
tvoss_duflu, apart from that, I'm fine04:49
duflutvoss_: I would prefer all read-only "getters" be const, regardless of the mutables required04:50
dufluIf they're not const then that creates problems for const callers04:51
tvoss_duflu, fair04:51
mhall119tvoss_: pong04:52
=== alf is now known as alf_
tvoss_mhall119, for your question what XMir: a vanilla Xorg which knows about Mir, credits to RAOF, here is the diffstat:04:53
tvoss_<RAOF>  ChangeLog                           |121618 ++++++++++++++++++++++++++++++++++++04:53
tvoss_<RAOF>  configure.ac                        |   1104:53
tvoss_<RAOF>  hw/xfree86/Makefile.am              |    904:53
tvoss_<RAOF>  hw/xfree86/common/xf86Bus.c         |    204:53
tvoss_<RAOF>  hw/xfree86/common/xf86Config.c      |   1204:53
tvoss_<RAOF>  hw/xfree86/common/xf86Globals.c     |    304:53
tvoss_<RAOF>  hw/xfree86/common/xf86Helper.c      |    904:53
tvoss_<RAOF>  hw/xfree86/common/xf86Init.c        |   5504:53
tvoss_<RAOF>  hw/xfree86/common/xf86Priv.h        |    304:54
tvoss_<RAOF>  hw/xfree86/xmir/Makefile.am         |   2604:54
tvoss_<RAOF>  hw/xfree86/xmir/xmir-output.c       |  22504:54
tvoss_<RAOF>  hw/xfree86/xmir/xmir-private.h      |   8304:54
mhall119probably should have pastebin'd that04:54
RAOFIgnore the ChangeLog addition, that's spurious :)04:55
tvoss_mhall119, probably, it's before third coffee here, don't expect me to be that clever04:55
tvoss_RAOF, mind pastebinning the diff-stat, then we can link it on G+, too04:55
mhall119it's almost 1am here, so I won't likely remember this in the morning anyway :)04:55
tvoss_mhall119, \o/04:55
* tvoss_ tries a sudo apt-get install kubuntu-desktop04:56
RAOFtvoss_: http://paste.ubuntu.com/5797514/ enjoy.04:56
tvoss_RAOF, thx04:56
RAOFtvoss_: Oh, any advance on the client-focus-notification thingies?04:58
tvoss_RAOF, nope, you just bumped its priority :)04:59
RAOFI would rather like to be able to switch sessions without having all input go to both :)04:59
tvoss_RAOF, that's a very sane requirement :)05:00
tvoss_RAOF, robert_ancell mind having a final look here and top-approve? https://code.launchpad.net/~vanvugt/mir/fix-119302005:07
robert_ancelltvoss_, duflu, approved05:10
tvoss_robert_ancell, thx05:10
duflurobert_ancell, ta05:12
* duflu -> lunch05:12
tvoss_duflu, enjoy05:13
RAOFrobert_ancell: Feel like approving https://code.launchpad.net/~didrocks/mir/packages-fix/+merge/171140 while I'm on a wait-for-CI-review-fest?05:17
robert_ancellRAOF, I don't know why he moved the demos to libexec - that doesn't make sense to me05:17
robert_ancellBut if you installed them, you do want to be easily able to run them05:18
robert_ancellit's not like they're in the main package05:18
didrockshey RAOF! I think this is perfect timing :)05:20
robert_ancelldidrocks, speak of the devil  :)05:20
robert_ancelldidrocks, why demos into libexec?05:20
didrocksrobert_ancell: hey! see RAOF's answer! https://code.launchpad.net/~didrocks/mir/packages-fix/+merge/171140/comments/38152105:21
tvoss_duflu, you've got a conflict on https://code.launchpad.net/~vanvugt/mir/fix-1193020/+merge/17107005:21
robert_ancelldidrocks, well, the manpages issue doesn't warrant them moving and if you install the package you expect them to be easily runnable05:21
didrocksrobert_ancell: and getting 8 demo_mir_ in your path? :)05:22
robert_ancelldidrocks, yes. The package contains 8 demo applications..05:23
didrocksrobert_ancell: I think as they are seeing as examples, we should do as for other demos, like the Qt ones and having them in a path that's not polluting the $PATH05:23
robert_ancelldidrocks, which qt package is this?05:23
didrocksrobert_ancell: http://packages.ubuntu.com/raring/i386/qt4-demos/filelist05:24
robert_ancelldidrocks, you can approve if you want05:27
tvoss_hmmmm, kubuntu-desktop seems to be in -proposed. didrocks, any idea when that is going to land?05:28
didrocksrobert_ancell: thanks!05:28
didrockstvoss_: kubuntu-desktop? did you look at the migration excuses?05:28
tvoss_didrocks, nope05:28
didrockstvoss_: are you sure about kubuntu-desktop? https://launchpad.net/ubuntu/+source/kubuntu-meta seems that it wasn't uploaded nor blocked for some days05:31
tvoss_didrocks, kubuntu-devel's topic says so :)05:31
didrocksrobert_ancell: I think kgunn gave to you the bug list we need to check before getting mir into distro?05:31
didrockstvoss_: well, I trust launchpad for facts, they are maybe talking about kde components, not the package05:32
tvoss_didrocks, ah okay05:32
didrockstvoss_: did you see my question on lttng* btw?05:32
didrocks(yesterday evening)05:32
robert_ancelldidrocks, yep05:33
didrocksThanks robert_ancell :)05:33
tvoss_didrocks, on irc? if so, bear with me, I was doing the session dance05:34
didrockstvoss_: ok, the question that colin and I had was libmirserverlttng.so and libmirclientlttng.so needs to be in system library path05:35
didrockstvoss_: as there is no ABI/soname, they normally should be seen as private lib05:35
didrocksso not really sure how lttng picks them, what's the mechanism?05:35
tvoss_didrocks, lttng does not pick them, they define and implement lttng probes that feed to the trace if activated05:35
tvoss_alf_, ^, mind helping out didrocks?05:36
tvoss_didrocks, I think they should have an ABI/soname, though05:36
didrockstvoss_: the question I guess is how are they activated? Do we tell lttng "please use those libs?"05:37
tvoss_didrocks, nope, the implementation in the libs tells lttng on activation: here I am05:38
tvoss_didrocks, so it's not a "plugin" to lttng05:38
didrockshum, I'm a little bit lost on the activation mecanism :)05:38
alf_didrocks: they are dlopened by Mir internally05:39
alf_didrocks: right now it's dlopen("limirclientlttng.so"...)05:39
didrocksalf_: ah, so we can install them in a private lib, rather?05:39
didrocksalf_: like /usr/lib/x86_64-linux-gnu/mir/tools/ ?05:40
alf_didrocks: Yes. In that case will I need to use the path when dlopen-ing or will the path be added to LD_LIBRARY_PATH externally?05:40
didrocksalf_: I think on compilation, we set that path in a .h for dlopen-ing, as we can multiarch it05:41
didrocksalf_: mind if we look at that together this morning?05:41
didrocks(like in a couple of hours)05:41
alf_didrocks: sure, ping me05:42
tvoss_alf_, where does the mir log go to, right now?05:48
RAOFtvoss_: You hunted down an “abort in global dtor” bug in the past, didn't you?05:48
tvoss_RAOF, yup, how can I help?05:49
alf_tvoss_: In stdout/stderr but it's not visible on the desktop since we put the VT in graphics mode. You can redirect it or use glog with a file output05:50
RAOFtvoss_: I'm shared-libbing mir-test-doubles (because I need their implementation of open() to be first in the link order), and the unit-tests fail with an abort in testing::internal::GTestLog::~GTestLog05:50
robert_ancelldidrocks, please review https://code.launchpad.net/~robert-ancell/mir/copyright-fix/+merge/17121505:51
tvoss_RAOF, let me have a look. Why are we hit by those fini issues? I still suspect -Bsymbolic-functions, with the linker unloading so's too early05:51
tvoss_RAOF, mind running it through ltrace real quick?05:53
robert_ancellbye all05:53
RAOFtvoss_: Not at all.05:53
RAOFrobert_ancell: Night.05:53
tvoss_robert_ancell, night05:53
didrocksrobert_ancell: have a good night!05:53
RAOFtvoss_: https://code.launchpad.net/~raof/mir/prober-drm-device-probe/ is the branch.05:54
RAOFWow, ltrace spews a lot of debug output :)05:55
tvoss_RAOF, yup, that's how tracked it down last time05:55
RAOFHm. I take it that “ltrace bin/unit-tests’ shouldn't deadlock? :)05:56
tvoss_RAOF, if that is the case, it's almost surely an issue in a pthread_mutex_destroy05:57
RAOFtvoss_: Oh, you mean “[ FATAL ] /home/chris/Canonical/Mir/mir/proper-drm-device-probe/3rd_party/gmock/gtest/include/gtest/internal/gtest-port.h:1486:: pthread_key_delete(key_)failed with error 22”?05:57
tvoss_RAOF, something like that :)05:57
RAOFSorry, should have given that output upfront!05:57
tvoss_RAOF, no worries05:58
tvoss_RAOF, building your branch right now05:58
tvoss_alf_, for the log: I would think something like /var/log/mir/mir.0.log makes sense05:58
tvoss_glog does log rotation, too05:58
tvoss_alf_, but I would expect the shells pulling in mir to be able to adjust that, so unity-system-compositor setting up the logging06:00
alf_tvoss_: makes sense06:01
tvoss_alf_, let me file a bug on usc06:02
duflutvoss_, and again :)  https://code.launchpad.net/~vanvugt/mir/fix-1193020/+merge/17107006:10
tvoss_duflu, didrocks do thread-local storage keys cease to exist on so unload?06:10
duflutvoss_: No, SOs are not tied to threads06:11
dufluAnd they have no automatic destructor06:11
tvoss_duflu, hmmm, so in the fini operation of unit-tests, a delete on a pthread key results in an error, although the key was existant before ...06:12
duflutvoss_ : You might have another SO/fini bug if it's an old distro06:13
tvoss_duflu, it's saucy06:13
dufluNot likely then06:13
tvoss_duflu, nope06:14
duflutvoss_: Also pthread_key_delete works by value. It's only an ID. So any error means the key is not a valid one... or you got heap corruption prior06:14
tvoss_duflu, right ... just waiting for my debug build to finish06:15
tvoss_didrocks, is there a list of changes to low-level userland stuff in saucy?06:15
didrockstvoss_: yeah, I confirm what duflu says, the libs are loaded globally to a process, weird that you have this pthread issue then06:15
didrockstvoss_: saucy-changes ML06:15
didrocksit's the only way to track what's in06:15
dufluI thought Linux was over these kinds of bugs. It's almost certainly an application bug06:15
didrocksstill some copyright issues to fix for robert :) https://code.launchpad.net/~robert-ancell/mir/copyright-fix/+merge/17121506:16
tvoss_duflu, right, but I wonder what makes it pop up right now06:16
didrocksthis deserves a coffee I guess now :p06:16
tvoss_didrocks, exactly06:17
tvoss_duflu, RAOF ah, heap corruptoin :)06:18
tvoss_at least gdb says so, valgrind to the rescue then06:19
tvoss_okay, there is heap corruption on fini of libmir-test-doubles.so06:22
tvoss_arising from a std::string::~string06:23
RAOFalf_: How much would you like a UdevEnumerator RAII wrapper? It's on my TODO list anyway.06:29
alf_RAOF: I don't consider it urgent enough to block the MP (especially if it's in the queue anyway).06:30
duflutvoss_, arising from std::string ?06:32
duflubuffer overrun?06:33
tvoss_duflu, checking06:33
tvoss_RAOF, did you just push an update to the prober branch?06:33
RAOFtvoss_: Yeah, but just stylistic changes.06:34
tvoss_RAOF, there are some stray characters in there :)06:34
RAOFHurray for stray non-printing characters!06:37
tvoss_RAOF, oh, and std::static_cast -> static_cast06:40
RAOFGot that one myself :)06:40
RAOFtvoss_, duflu: Looks like it's double free()ing the string?06:46
tvoss_RAOF, yeah, but it's racy and I'm not able to track down the string location06:47
duflutvoss_: Is it a static global? Those can easily get double freed06:47
tvoss_duflu, already searched for static std::string, nothing test-doubles, next is look through source files and see if we have global strings somewhere06:47
tvoss_duflu, although fini should be threadsafe, shouldn't it?06:48
RAOFHappens when having an indirect link of libmirserver006:48
duflutvoss_: Well, no I don't think so. Fini doesn't have to be thread safe. It's only every called once, in theory06:48
duflutvoss_: Ah linking to client & server libraries?06:49
RAOFIt does do that, yes.06:49
dufluIf so then it can happen if there is a global symbol of the same name (as in our input code that's duplicated)06:49
dufluThe first loaded copy gets destructed twice. And the second, never.06:49
dufluOr not global, but a static class member even06:50
dufluThe solution is to replace it with a static getter function that returns a reference to the real variable (which is static inside the getter function)06:50
didrocksis it me or Mir trunk doesn't build anymore?06:52
tvoss_duflu, okay, let me scan through the code06:52
tvoss_didrocks, it's obviously you ;)06:52
duflutvoss_: See r566 as an example06:52
didrockstvoss_: saucy, right?06:52
tvoss_duflu, although it's a question whether this is faulty linker behavior06:53
duflutvoss_, that's a premature and usually naiive argument :)06:54
tvoss_didrocks, ack06:54
tvoss_duflu, well, my suspicion is that if you remove -Bsymbolic, it wouldn't result in issues06:54
duflutvoss_, Yeah you're probably right. But you can modify statics like in r566 so you don't need to remove Bsymbolic06:55
tvoss_duflu, I rarely blame the compiler or the linker, but the exposed behavior contradicts the c++ standard. Not saying that is bad necessarily!06:55
RAOFSurvey suggests that 3rd_party/gmock/gtest/include/gtest/internal/gtest-death-test-internal.h:  static std::string last_death_test_message_; is a possible culprit.06:56
dufluWell, linkage rules are outside the scope of C* languages, unfortunately06:56
didrockstvoss_: let's say I'm blaming ccache and I retry without it07:00
tvoss_didrocks, branching trunk now :)07:00
didrockstvoss_: I think it's fine, seems to be ccache + parallel build not playing fine07:01
duflutvoss_, thanks for fixing my bug without even being aware :)07:05
ubot5Launchpad bug 1194054 in Mir "--vt N option seems to be unreliable/racing" [Medium,Fix committed]07:05
tvoss_duflu, \o/07:06
tvoss_didrocks, ack07:07
didrockstvoss_: duflu: RAOF: alf_: does mirplatformgraphics really belong to the same binary package than libmirserver0?07:10
didrocks(it will follow the same ABI stability I guess?)07:11
RAOFOh, has loadable backends landed?07:11
dufludidrocks: They share all their code, and we fully expect parts to move around between them as a driver model materializes07:11
RAOFFor the moment it's certainly in libmirserver007:11
dufluRAOF: Landed yes, but it's just the old library made dynamic instead of static07:11
alf_didrocks: In the future I would expect to have separate packages for the various backends07:12
didrocksRAOF: duflu: alf_: ok, let's keep it that way, then, thanks!07:12
* didrocks remerges his branch and multiarch that one as well before pushing07:12
tvoss_duflu, idea for testing vt's: we request the next free vt and do all of the activation magic and modesetting there07:14
tvoss_RAOF, duflu any idea how we can get vts back?07:17
RAOFECONTEXT. Back from what?07:17
duflutvoss_: Ctrl+Alt+F7 to regular X, and then back to your VT (https://bugs.launchpad.net/mir/+bug/1189770)07:18
ubot5Launchpad bug 1189770 in Mir "[regression] Killing Mir with Ctrl+C often leaves the screen blank and difficult to recover " [High,Triaged]07:18
duflutvoss_: I'm not sure any automated tests should be touching real hardware, by default... ?07:20
tvoss_duflu, not sure that the trick works. Can we fix that issue somehow?07:20
duflutvoss_: Not sure. Maybe our SIGINT handler needs to do cleaner shutdown07:23
dufluWhich is simple07:23
dufluHaven't looked07:23
duflutvoss_: The trick doesn't work if you're using unity-system-compositor :(07:34
tvossokay, found the reason for the double free07:54
tvossbut: that still does not solve the issue with the std::string dtor07:55
tvossRAOF, ^07:55
RAOFtvoss: How did you find the double-free?07:59
RAOFAlso, what is it? :)07:59
tvossRAOF, let me pastebin the diff07:59
RAOFHm, or not :)08:02
tvoss_RAOF, hold on, compiling :)08:12
tvoss_RAOF, http://pastebin.ubuntu.com/5797856/08:15
tvoss_RAOF, there is still some issue reported by valgrind about an invalid free in a string08:17
tvoss_RAOF, and busid is a std::string now08:17
hikikoquestion :)08:20
hikikohttp://unity.ubuntu.com/mir/namespacemir_1_1compositor.html I am looking at the classes here, trying to understand the system and the session compositor... but I am a bit confused08:21
hikikothe system compositor is the Multithreaded Compositor?08:22
tvoss_hikiko, nope, why should it? the system compositor is a process on its own08:23
hikikotvoss_, could you explain me a bit the concept with the 2 compositors or tell me the classes to look at?08:24
hikikosystem compositor == the whole mir?08:25
tvoss_hikiko, no need to look at classes: every compositor is the whole of mir08:25
tvoss_hikiko, the session compositor is just another client to the system compositor08:25
tvoss_hikiko, both are independent processes08:26
hikikoevery client == session compositor?08:26
RAOFhikiko: Every client of the system compositor is a session compositor.08:27
tvoss_hikiko, nope, ordinary apps talk to the session compositor08:27
hikikohmm I think that my problem then is that I didn't get what exactly the compositor does :S08:27
hikikoin case of mir server I understand08:27
RAOFIsh; we may well have a couple of non-compositor clients of the system compositor (such as a polkit authenticator)08:27
hikikoIt combines/renders the win to a surface08:27
tvoss_hikiko, it takes buffers and assembles a final output08:27
tvoss_hikiko, in case of the system comp, that is sent to the display08:28
tvoss_hikiko, in case of the session comp, that is sent to the system comp.08:28
hikikoso the windows of a client08:29
hikikoare assembled before being sent to the server08:29
hikikoand the server only displays the buffer with all the windows?08:30
tvoss_hikiko, no, the windows of clients are surfaces known to the session comp08:30
hikikoso why the session compositor needs the server?08:30
tvoss_hikiko, the session compositor is a server in itself. And: it does not know about displays and such and does not have access to the underlying hw08:31
tvoss_hikiko, think about user session swithcing: all of these sessions are clients to the system comp08:31
hikikoI think I misunderstood what we call session then :s08:32
tvoss_hikiko, ?08:32
hikikotvoss_, let's say we have a client (a program that needs to open 2 windows)08:33
tvoss_hikiko, what did you consider a session if not a user session?08:33
tvoss_hikiko, okay08:33
hikikoa client connection08:33
hikikobut I am wrong obviously :)08:33
hikikoin the example with the 2 windows of a client08:34
hikikothe process is:08:34
RAOFWe do have a concept of "session" in the codebase, don't we.08:34
tvoss_RAOF, yup, every application is a session08:34
hikikothen I was right?08:34
tvoss_hikiko, nope08:34
RAOFtvoss_: So, it's not entirely strange to be confused about the overloaded “session” nomenclature :)08:34
tvoss_RAOF, it is overloaded for a good reason: all sessions are connections in the end08:35
hikikook what I am trying to understand is how mir would render the 2 windows of a client step by step08:35
hikikobecause then everything mir does will be clear08:36
hikikostep 1: connection?08:36
RAOFhikiko: You can think of it like this - the system compositor is a Mir server that takes the contents of user-sessions (like Unity, GNOME, etc - a user login) and composites them to the hardware.08:36
hikikoso all the unity programs08:36
tvoss_hikiko, step 1: ack08:36
hikikoare part of 1 session?08:36
RAOFhikiko: A session compositor is a Mir server that takes all the windows of a user's login and composites them into the user-session.08:36
tvoss_hikiko, ack08:37
hikikooh I see :) then I was completely wrong :)08:37
hikikook so, we composite every unity window on the client08:37
hikikoand then08:38
hikikowhat we do with the server?08:38
tvoss_hikiko, hold on: what do you mean by "On the client"08:38
hikikoI mean08:38
hikikoif we start unity on a pc08:38
hikikowe have 1 buffer for each window08:38
hikikowe combine these buffers on a large buffer08:39
hikikoand then we sent it to mir08:39
RAOFAh, no.08:39
tvoss_hikiko, nope08:39
RAOFWe have one buffer for each window.08:39
tvoss_hikiko, the combination of the buffers is done by mir, too08:39
RAOFA mir server combines these buffers onto a large buffer.08:39
RAOFAnd sends that large buffer off to a mir server.08:39
RAOFWhich combines the large buffers onto the framebuffer.08:39
hikikothis is the same mir server?08:40
tvoss_hikiko, nope, two processes08:40
RAOFNo, two different mir servers.08:40
RAOFThe first Mir server - the one that all the user's applications run in - is called the session compositor, because it takes all the windows of the user's session and composites them.08:41
RAOFThe second Mir server - the one that all the session compositors talk to - is called the system compositor, because it takes the outputs of all the sessions and composites them onto the system's displays.08:41
hikikoand why we need to composite once in a buffer and once in the framebuffer?08:42
RAOFIt makes things easier.08:43
hikikowe can't do the composition directly in the framebuffer?08:43
tvoss_hikiko, we can, but we don't want for the session compositor in the first place08:43
RAOFSpecifically - it makes running different users, and handling the transitions between them - easier.08:43
hikikook :)08:43
tvoss_RAOF, plus: suspend/resume etc.08:44
RAOFtvoss_: And boot splash → greeter → session, yeah.08:44
hikikoactually i thought that we only compose once at the framebuffer and the session compositor was for a program's windows completely different from what we actually do :)08:44
hikikothat's why I was so confused08:44
hikikoso in my case the nested mir will have 2 server processes as well08:45
RAOFI'm not sure what you mean.08:46
RAOFThere'll only be one nested server process (per user)08:47
RAOFBut there'll be a nested server process and the system server process, yes.08:47
hikikoyes that's what I mean :) sorry I cant make myself very clear08:48
hikikoand RAOF08:48
hikikothe nested mir clients08:48
hikikowill use the nested mir session compositor08:48
RAOFtvoss_: What does that patch fix? I see exactly the same crash and exactly the same valgrind double free?08:48
RAOFhikiko: Right.08:49
hikikoso I have to change it to use a different socket for the clients08:49
tvoss_RAOF, it get's rid of a spurious double free during repeated test execution of bin/unit-tests08:49
hikikoisn't it?08:49
RAOFhikiko: Yes; there'll be two sockets - the system compositor's socket, and the session compositor (nested) socket.08:50
hikikoRAOF, which classes implement the session compositor to get a look at? I guess the directory compositor is for the system compositor isn't it?08:50
RAOFhikiko: The session compositors and system compositors live outside mir; there isn't a class to implement.08:51
RAOFtvoss_: Ah, ok. So it doesn't do anything about the double free() on shutdown, then.08:51
tvoss_RAOF, not yet, still tracking down08:52
hikikoso, i guess I have to look at the examples :)08:53
RAOFhikiko: What needs to be done for the nested compositor is implementing src/server/graphics/nested-gbm.08:53
hikikoand add some code to keep a socket where the nested_gbm accepts connections?08:54
RAOFHm, yes. That too.08:54
hikikocool :) I am going to start this thanks a lot RAOF and tvoss_ :)08:55
tvoss_hikiko, would you mind keeping us posted how you come along? I think we can help unblock you in case of questions/issues easily08:56
tvoss_raof, it seems like the gpu hang on intel is mostly caused by chrome08:59
RAOFThat's inconvenient.08:59
tvoss_RAOF, it is, but it also happens on vanilla x occasionally08:59
RAOFUpstream's also not going to be particularly helpful until I finish the SNA xmir implementation, either.09:00
hikikosure tvoss_ atm I have only done a platform/display that compile but do nothing and now I'll try this socket change to test what Ive done using clients :)09:00
RAOFDownloading libstdc++ source. Things can only get more awesome.09:01
hikikoRAOF, and tvoss_ sorry but I have another question09:03
RAOFGo ahead!09:04
hikikoI understood it :) I was wondering what happens with the z order if we have 2 compositors but then I remembered that we composite all the user program windows in the buffer compositor (session) so there's no problem09:07
hikikoif we have 2 windows*09:07
hikikoof the same program09:07
hikikobut ok09:07
hikikothere's no problem09:07
tvossRAOF, for chrome/hangouts: if running firefox without using hangouts -> stable. Hangout in Firefox: almost immediate hang09:16
didrocksalf: ok, I've now the *ttng* modules installed in <libexecdir>/mir/tools/ for lp:~didrocks/mir/move-lttng-libs09:25
didrocksalf: you just need to change the dlopening I guess09:26
tvossRAOF, hah09:30
RAOFtvoss: Oh, win?09:31
tvossRAOF, the pthread_key is indeed removed twice, with the second attempt failing09:32
tvossRAOF, it's triggered by GTEST_API_ extern ThreadLocal<Sequence*> g_gmock_implicit_sequence;09:33
alfdidrocks: thanks, I will take a look a bit later09:39
mlankhorsthow are hybrid display outputs handled with mir?09:40
RAOFmlankhorst: At the moment? They're not.09:52
mlankhorstcould it be made to work? :p09:52
mlankhorstwhat pieces are missing atm?09:52
RAOFtvoss: valgrind+gdb suggest that testing::FLAGS_gmock_verbose might be the std::string being double-freed.09:53
tvossRAOF, I really don't understand why we are seeing such issues popping up right now09:54
RAOFmlankhorst: The gbm platform would need to open both drm devices, rather than just the first. Then we'd need to create an EGL context on both. Then we'd need to handle multiple monitors in a less stupid way ;)09:54
tvossmlankhorst, alf is the right guy to talk to :)09:54
RAOFtvoss: I'd guess it's because we don't link both mirclient and mirserver in to anything else?09:54
RAOFOr, at least, we don't link against anything that links against both mirclient and mirserver?09:55
mlankhorstI could probably use the xorg code as an example for drm device detection, we need to talk to udev anyway for this09:55
tvossmlankhorst, we are having parts of that under review right now :)09:55
RAOFmlankhorst: Correct. See lp:~raof/mir/prober-drm-device-probe :)09:55
RAOFmlankhorst: For simple proof-of-concept GPU offloading you could probably get away with just opening both devices, handing one drm device to the GBMDisplay and the other to the GBMBufferAllocator.09:56
RAOFmlankhorst: Then you'd have display on one device and rendering on the other.09:57
mlankhorstRAOF: xorg doesn't like hybrids ;)09:57
mlankhorstin mir09:57
RAOFmlankhorst: Correct. I disabled gpu-only loading, didn't I?09:57
RAOFOr was that only for -radeon?09:57
mlankhorstthe thing has outputs so it works09:57
mlankhorstI have one without outputs to test too09:57
RAOFThe one without outputs will now start Mir on the device that *has* outputs!09:58
RAOF8pm is probably EOD.09:58
RAOFSo long, chappies!09:59
mlankhorstsee ya mateQ!09:59
dufluRAOF: Bye. And mee too10:00
dufluSee, I can't even type any more10:01
mlankhorstRAOF: btw that code is too difficult, you don't need to use setversion to test10:03
tvossRAOF, so long :)10:04
mlankhorstRAOF: use drmModeGetResources(fd); if it returns NULL KMS is not supported on that node, and it should be ignored entirely (nvidia blob for example). After that just check ret->count_connectors and use drmModeFreeResources10:04
mlankhorstI only found out after checking with upstream, but it's the cheapest test, no need to traverse udev or anything like that..10:08
mlankhorstRAOF: http://paste.debian.net/12543/ .. not even compile time tested :>10:18
mlankhorstoh it could be better still10:19
tvossRAOF, okay, for the pthread_key_delete issue: the global initializer is executed twice10:19
tvossdidrocks, ^10:19
mlankhorstopen syspath/boot_vga, read it and if it's == '1' there you go, this one is the primary10:20
didrockstvoss: rings to me like a bell, didn't we get something like that already hard to decipher?10:20
tvossdidrocks, yup, look here: http://pastebin.ubuntu.com/5798108/10:21
tvossdidrocks, it executes the c'tor for the global object twice, for the same this pointer10:21
didrockstvoss: indeed, good catch!10:28
tvossdidrocks, well, at least it's reproducible on my machine10:30
tvossquick lunch10:43
=== tvoss is now known as tvoss|quick_lunc
=== tvoss|quick_lunc is now known as tvoss
=== mmrazik is now known as mmrazik|afk
=== mmrazik|afk is now known as mmrazik
greybackracarr: who good to ask these questions to: http://studio.sketchpad.cc/flleQTzi4o14:36
greybackthey're some Mir comments and questions I've assembled the last day or 214:36
=== mmrazik is now known as mmrazik|afk
kgunnkdub: mornin'15:27
didrocksalf: hey, any luck? :)15:38
alfdidrocks: sorry, not yet (and probably not today), I was caught up in other work. I will take a look first thing tomorrow15:42
didrocksalf: ok good :)15:43
didrocksalf: should we open a bug for that add the tag so that kgunn can know exactly what's blocking Mir in distro?15:43
kgunndidrocks: alf....shoot me the link when there15:53
didrockskgunn: added to https://bugs.launchpad.net/mir/+bugs?field.tag=entering-saucy15:56
ollialf, still around15:57
kgunndidrocks: thanks....alf i'll try to get alan to look at when he returns...please stay on snapshot/mm15:57
alfolli: intermittently :)15:58
alfdidrocks: thanks15:58
didrocksyw :)15:58
ollialf, I noticed some variance in 2 consecutive glmark2 runs on the same system15:58
olliis this expected/possible15:58
didrocksolli: reiterating that if you want me to comment on the google doc, please give me comment rights :)15:58
ollior do I need to check my background processes15:59
ollididrocks, didn't get to it yet15:59
didrocksolli: no worry, just wanted to ensure you read my request ;)15:59
alfolli: What kind of environment are you running glmark2 in?15:59
ollialf, xmir on intel15:59
kgunnolli: cpu load can effect benchmarks...altho, you'd have to have alot of stuff going on15:59
alfolli: how much variance do you see?16:00
ollididrocks, done16:00
ollialf, I got ~900 on saucy stock16:00
olliand then ~900 on saucy/xmir16:00
ollior 700 saucy xmir16:00
didrocksolli: danke schön16:00
olliI hadn't measured multiple runs on stock saucy though16:01
kgunnolli: can you do same for openarena?16:01
kgunnolli: btw, my system fixed :)16:01
ollialf, I'd assume that in general a small deviation (few %) are anticipated but not ~25%16:01
alfolli: right, 700->900 is not normal variance16:02
kgunnaltho...hit one of the legit bugs that prevented me from running xmir (i can do the client demos tho)16:02
kgunnolli: alf  i loathe the nebulous agregate # from benchmarks....fps are best16:02
kgunnopenarena is sub 6016:02
kgunnso it would be a better metric16:02
ollikgunn, I am working with chrisGagnon to get some repeatable tests in place16:03
kgunnolli: much thanks on that16:03
didrocksolli: testing playing openarena? I see :-)16:40
Guest36302gpg: skipped "Robert Carr <robert.carr@canonical.com>": secret key not available17:09
Guest36302Keep getting this when trying MIR17:10
kdubgive out your secret key racarr ;-)17:10
Guest36302debuild -i -I17:12
Guest36302after this command is when I receive the message17:12
kdubperhaps the debian/changelog does not have your email as the latest entry?17:12
Guest36302ah, probably.  I guess this means I need to be logged into bzr17:13
racarrMy secret key is 21.17:14
racarrInsist on doing RSA in my head.17:14
racarrGuest36302: There is some flag you can pass to not sign that I don't remember or you can do dch -i and add an entry for yourself17:14
=== dpm is now known as dpm-afk
=== mhall119_ is now known as mhall119
racarrIm going to attempt to refactor17:25
racarrthe focus bits of the SessionManager17:25
racarrand the_focus_mechanism17:26
racarrand the_focus_sequence17:26
racarrin to something sensible for the shell...probably a single FocusArbitrator17:26
racarrdoes anyone have any thoughts?17:26
racarr on refactoring the focus machinery, not in general :p17:26
racarrkdub: Also I was wondering has anything come out of seperating surface state from msh::Surface17:27
racarrgreyback is asking for API to be notified on surface state change17:27
racarrand that's weird at the moment17:27
racarrbecause you don't want to subclass the surface17:27
kdubracarr, well, still untangling dependencies a bit17:27
racarrbut its not clear that17:27
racarris really the proper interface here.17:27
kdubno, probably not :)17:27
racarrsometimes I wish we just had signals17:28
kdubreally, this is that 'interface' that i've been going on about...17:28
racarrkdub: Aha. mir::shell::Interface17:28
kdubfrom the shell's perspective, I think that a 'ask-decide-command' (wrt the surfaces) is a good way to go, as opposed to having a notification signal17:30
kdubthis is probably a bit off topic from the 'FocusArbitrator" that you were talking about17:31
racarrwell, I mean signals can have responses, I guess what I meant by signal17:31
racarris that a subscription17:31
racarrpattern is easiest17:31
racarrbut often gets17:31
racarrwhereas we use...17:31
racarrI don't know what the opposite of a subscription pattern is XD17:32
racarrbut explicit listeners, etc.17:32
kdubwell, the opposite is :) keeping the state in one place17:32
racarrhmm sort of17:32
racarrI just mean we don't have any APIs like17:32
kdubwhat I mean by that is... if we have a callback signal, we 'im the shell, and the last time mir callbacked me, the position is at x1, y1'17:33
racarrthey are all through the configuration17:33
kdubin addition to 'im mir, and I think the state is at x1, y1'17:33
kdubi like that :)17:33
racarrI think it's worthwhile yeah.17:34
kdubmir says, 'hey, new surface arrived over ipc, ask me about it'17:34
kdubinstead of saying ' a new surface arrived, here's the details, but... this is just an echo of the state'17:34
kdubi guess I just want state to 'flow' into the right components17:35
kdubinstead of having a gob of state bunched up in a common place17:35
=== thomi_ is now known as thomi
racarrthomi: Hey!20:28
racarrnow that qtubuntu and platform api mir are packaged and in PPAs20:29
racarrI think we should do some sort of20:29
racarrintegration testing?20:29
racarrcontinuous integration?20:29
racarr*waves hands*20:29
racarrI dunno, I imagine like, we have the staging PPA, where everything just lands and it's built20:29
racarrbut then to make it in to the next PPA or some such, i.e. phone-testing-ppa20:30
racarrsome integration test has to pass that brings up Qt clients, does some autopiloting20:30
thomiracarr: maybe send me instructions on what I need to do to try this myself?20:33
thomiis it as simple as adding the PPA and dist-upgrading? Or is there some manual configuration involved?20:33
racarrthomi: Um. well now that I think of it right now the packages are only buitl on arm XD20:38
racarrso maybe its too soon20:38
thomiracarr: hmm, are there plans to build for other archs?20:40
racarrthomi: Yeah, it's just not under CI yet because we are still waiting on the qtubuntu changes to land20:45
racarrso it's under ricmm integration ATM20:45
thomiracarr: ok20:49
thomiprobably best to wait a bit then20:50
racarrOk :)20:50
=== seb128_ is now known as seb128
=== seb128_ is now known as seb128
=== seb128_ is now known as seb128
=== seb128_ is now known as seb128
mterryracarr, I'm following the mir-with-unity sketchpad instructions again, filling them out to be more fool-proof.  But I ran into a problem building qtubuntu:21:45
mterry../ubuntucommon/libqubuntucommon.a(integration.o): In function `QUbuntuIntegration::createPlatformWindow(QWindow*)':21:46
mterry/home/phablet/tmp/qtubuntu/mir-with-packaging/src/platforms/ubuntucommon/integration.cc:140: undefined reference to `ua_ui_session_properties_set_remote_pid'21:46
mterrycollect2: error: ld returned 1 exit status21:46
racarrmterry: https://code.launchpad.net/~robertcarr/platform-api/missing-mir-stub21:52
racarrmerged with r73 of papi21:52
mterryracarr, aweosome21:54
mterryracarr, what is the a for in ua_?  api?21:54
racarrmterry: application22:00
robert_ancellRAOF, did that gbm debugging help>22:19
* kdub enters the swamp22:51
kdubracarr, event sinks... are they per-surface, or per-session?23:20
kdubor rather, :) they are per-surface at the moment, could they be per-session?23:21
racarrkdub: They are per session23:40
racarrkdub: Handed by the session to each of it's surfaces23:41
kdubah, yeah23:42
robert_ancellmterry, still there?23:45
RAOFGah. What happened to all my beautiful backscroll?23:53
racarrRAOF: You missed some pretty juicy stuff.23:56
racarrA lot of things were said about you, I'm not sure they are appropriate to repeat.23:56
racarrkdub: Kind of out of the blue but you may have an opinion on this as it ties in a bit with the structure of msh::Surface23:58
racarrmore with Session I guess.23:58
kdubracarr, pass one is just to lift these factories out of being so deep23:58
racarrkdub: So, in my attempt to refactor focus23:59
racarrErr, trying to find the best way to explain, sorry23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!