[00:06] hi [00:06] anyone around? [00:17] ricmm: Sure; best to actually ask your question, though. [00:20] RAOF: seeing this with latest Mir in the phone image that runs unity-mir [00:20] http://pastebin.ubuntu.com/5938197/ [00:20] catching a SIGBUS there [00:20] any ideas? [00:20] examples run fine [00:24] Hm. Nothing obviously springs to mind. [00:24] Except that SIGBUS is one of those fun errors that's only ever going to occur on armd [00:24] oh hmm [00:25] Oh, hey, arm guy! [00:26] ricmm, we moved that code between libraries recently, perhaps something isnt updated [00:26] i'll try it, one minute [00:27] thanks kevin [00:35] kdub_: any clues? [00:40] ricmm, i'm not seeing any problems with the example programs i have [00:40] not set up for the unity-mir though on this device at the moment [00:42] can you think of any API changes that might've triggered this? [00:44] no :/ [00:44] ricmm, actually, yes! [00:45] :) [00:45] we changed the way that the display size is handed out, perhaps there's something amiss there [00:45] it should be backward-compatible though... [00:46] but if something is wrong, mabye its trying to make a surface that's a nonsense size [00:48] lemme catch the call to create_surface and see the params [00:51] kdub_: http://pastebin.ubuntu.com/5938258/ [00:52] size looks fine, it has been working like this before [00:52] depth 0 means anything? [00:52] right, that looks fine [00:54] depth 0 is just the stack ordering position, its ok [00:57] what change with the size passing? [00:58] that was a client side api change, this is an internal client, so what i mentioned probably won't affect anything [05:20] RAOF: ping [05:20] duflu: pong [05:20] Would you quite like to talk bypass? [05:20] RAOF: I've removed the explicit (and slightly hacky) workaround fix for the input lag bug... but suspect it might still be fixed by that branch. Can you retest? [05:20] RAOF: No bypass this week :( [05:21] duflu: Still the "switch" branch? [05:21] RAOF: Yes. [05:21] I'll give it a try. It may take me a little while to get to that. [05:22] RAOF: Actually, maybe wait. I might try to do an independent fix for that bug [05:23] Excellent. The best kind of testing :) [05:28] RAOF: I just realized, even if my branch eliminates the cause of the bug under double buffering, it introduces triple buffering which is expected to cause the same bug. I think we need to fix the compositor... [05:29] ok [05:48] Ok. Who changed the mir_connection_get_display_info ABI on me? [05:52] * duflu points to multimonitor guys [06:01] Ahem. [06:01] Yes, that commit did indeed break mir_connection_get_display_info [06:04] Grr. I wonder what's easier. Fixing mir_connection_get_display_info, or switching to the new API. [06:04] good morning :) [06:04] RAOF: Robert was right when he said "everyone forgets to bump ABIs" [06:04] Morning tvoss_ [06:05] duflu, good morning [06:05] duflu: This isn't actually a deliberate ABI break. This is just a buggy implementation of the deprecated function. [06:09] * RAOF 's symbol file branch wouldn't have helped here [06:16] Ok. Whoever wrote the mir_connection_get_display_info was too trusting :) [06:17] Ok. I'm going to go and collect something; back in 20 minutes or so. Then I'll fix this. [06:19] RAOF, see you :) [06:19] duflu, on the switch branch: Alf mentioned that it might break the mm use-case he is working on [06:19] did you have a chance to look into that? [06:19] tvoss_: Yes I have a fix/workaround in mind. [06:20] ... but still think we need a more robust solution later, as discussed with alf a while back [06:20] duflu, okay, what would be your proposal to move forward? [06:21] tvoss_: I'll do a fix/workaround to work with the existing mm logic today, I hope [06:21] Just saying I think the MM assumptions are wrong/unsafe [06:21] duflu, existing as in what alf and kdub are landing right now? [06:22] tvoss_: Yes I've discussed it with alf already [06:22] duflu, ack. I will grab some breakfast and be back after that [06:22] duflu: What's unsafe about the MM assumptions? [06:24] alf__: The assumption that each monitor will compositor_acquire at roughly the same time. I think we need better guarantees that it only happens once per vsync [06:24] But I will do a workaround in the switch branch, which should work in theory [06:25] duflu: the problem is that we don't have a single vsync, we have as many vsyncs as outputs [06:26] alf__: Yes, I know. I can probably defer the discussion if I can workaround in switch before my EOD [06:27] duflu: ok, I would be interested in any sane alternatives, but I don't have any in mind [06:27] It will be a blocker for bypass though. Which is why I've changed it... [06:28] duflu: I guess that indicates that it needs to be configurable. At this point it doesn't seem that we can have a one size fits all swapper. [06:29] alf__: I've had a few ideas. But am too rushed to revisit today. I'll try and give you a workaround in the switch branch tho [06:29] duflu, alf__ we should tackle that together on Monday morning. [06:35] alf__: The squashed render_surfaces issue seems to be triggered by my lazy allocation optimization. render_surfaces' RenderResourcesBufferInitializer is making the poor assumption about when it is executed, and interacting with the wrong GL context [06:41] alf__: So I'm wondering if I should disable the optimization or leave the render_surfaces bug for fixing separately? [06:44] duflu: what resource are you allocating lazily? [06:45] alf__: The buffers [06:47] alf__: Aha! Never mind. I have a simple fix [06:58] Strange jenkins error on no-input-for-hidden-surfaces [06:58] is what racarr would be wondering about if he were awake ;) [07:00] racarr, welcome to Friday [07:02] alf__: Hey, so mir_connection_get_display_info is broken. What should I be fixing - the false assumption that config->displays[0] is always valid if num_displays > 1, or making that assumption true? [07:07] RAOF: the false assumption that config->displays[0] is always valid (if by valid you mean connected and used) [07:07] alf__: Good, that's what I'm in the process of doing. [07:09] RAOF: hmm, config->displays should be config->outputs... [07:10] Quite true. [07:10] RAOF: Do you want to wait a moment so I can fix that? [07:11] Ok [07:11] RAOF: so you don't have to make another change soon, but whatever is more convenient for you [07:11] Well, this is blocking me now, and the update will be trivial. [07:14] RAOF: ok, then feel free to change it now and I will ping you for an update (perhaps we need to wait until Monday to push the s/display/output/ change so we don't break everything) [07:14] Ideally we'd land this at the same time. [07:14] Actually, no. [07:14] We're breaking ABI, so your change bumps SONAME regardless. [07:14] Monday is fine. [07:15] RAOF: if I push the change today will it break the packages? [07:15] Not any more than the packages are currently broken. [07:16] RAOF: (I assume so, since you won't be able to update the mesa/x again until next week) [07:19] RAOF: ok, either Kevin or I will have an MP ready for you. When you feel like it next week approve it and make the Mesa/X changes at your convenience. [07:19] It actually doesn't change X or Mesa (at this point), so we kindof could get away with silently breaking ABI. [07:20] RAOF: ok, where is the breakage then? [07:20] mir_connection_get_display_info segfaults [07:20] Because its implementation assumes that config->displays[0] is always valid. [07:21] RAOF: sorry, I misunderstood the whole discussion, looking [07:25] RAOF: ok, feel free to make the change and we can rename afterwards (hopefully later today) [07:25] Hm. We've got no tests for mir_connection_get_display_info. [07:26] RAOF: I am sure we had... I guess they were remove when introducing the new API [07:26] Indeed. [07:27] didrocks: Good morning. [07:27] How goes IoM? [07:28] hey RAOF! [07:28] RAOF: foggy? ;) [07:28] how is the other side of the planet? [07:28] Darkening! [07:35] alf__: https://code.launchpad.net/~raof/mir/fix-mir_connection_get_display_info/+merge/178216 is there for your viewing pleasure. [07:38] RAOF: a more reliable test would be to check that (.used == 1 and .connected == 1 and .current_mode < .num_modes) [07:38] RAOF: btw, any luck with testing xmir/xorg and upload that to distro? [07:38] (or still building?) [07:40] didrocks: See conversation above. The libmirclient1 that landed this morning broke xmir. [07:40] *Apart* from that, everything seems to be good to go. [07:40] :) [07:41] RAOF: ahah, ok, so once your MP merged, I need to repush mir to distro [07:41] then you push all the crack [07:41] we promote [07:41] and then u-s-c [07:49] alf__: For future-proofing can we not test booleans against "1" ? :) [07:49] *"can we please not" [07:52] duflu: sure :) [07:52] alf__: Thanks [07:53] RAOF, hey, can you do a quick triage on bug 1206744 [07:53] bug 1206744 in XMir "black screen on nvidia gt640 with system-compositor-testing ppa" [Critical,New] https://launchpad.net/bugs/1206744 [07:53] Bah! What's happened to radeon? [07:54] RAOF: hmm, test failure about uninitialized variable [07:55] Hm, quite true. [07:55] Why didn't that error locally? [08:04] Evening Zoë time. === alan_g|EOD is now known as alan_g [08:22] Back in 20ish [08:33] hikiko: you've not addressed https://code.launchpad.net/~hikiko/mir/mir.nested-mode-connection/+merge/178042/comments/401241 - should be a 5 minute job? [08:38] I ve fixed i t already alan_g :) [08:38] pushing! [08:38] oh no [08:39] alf__: ^ - want to re-review? [08:39] I was referring to another comment [08:39] sorry [08:39] you mean to replace MirConnection* with unique_ptr? [08:39] https://code.launchpad.net/~hikiko/mir/mir.nested-mode-connection/+merge/178042/comments/401765 [08:40] I am pushing this fix [08:43] hikiko: it is better to resolve "Needs Fixing" comments than "Comment" comments. [08:44] yes I pushed alex's changes except the MirConnection* [08:44] do we really need this? [08:45] (because we use it once) [08:45] and never again [08:46] hikiko: because we throw in the constructor the destructor never executes. So the connection is leaked. [08:46] oh [08:47] i see [08:47] unique_ptr isn't IMO the cleanest solution - I'd write an RAII class [08:47] sorry if I sound too naive but I don't know what a RAII class is [08:48] http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization [08:48] is it this?^ [08:48] hikiko: yes [08:50] cool :) I'll read it (I've never used it before) [09:09] * duflu is not a fan of RAII. Most notably because it confuses object destruction for resource close. If you for example "delete my_file", that does not delete or destroy the file like destruction usually implies [09:14] * alan_g Likes RAII - but thinks it should be called "use destructors for paired operations" [09:20] guys [09:20] i've come across [09:20] class ForwardingInternalSurface : public mg::InternalSurface [09:20] with the comment [09:20] // TODO this ought to be provided by the library [09:20] tsdgeos: ack I wrote that [09:20] I agree, since i think i need something similar to make http://bazaar.launchpad.net/~phablet-team/platform-api/mir-packaging/ compile again [09:21] so i copy that class in there or? [09:24] tsdgeos: you could as a workaround. I'll be fixing that in a few days (sorry didn't know of your dependency) [09:24] ok [09:24] will do === hikiko is now known as hikiko|afk|brb === hikiko|afk|brb is now known as hikiko [09:53] alf__: MP should be fixed; review at your leisure. [09:53] RAOF: great, thanks [10:00] RAOF: I proposed a new, different, fix for the lag bug, if you wish to continue hacking into the night :) [10:01] * duflu -> dinner [10:17] didrocks: Hey, it's ok for me to upload the stack before that mir fix lands, isn't it? It'll be blocked in -proposed until everything works? [10:18] RAOF: it will be blocked in -proposed until someone put mir in main [10:19] RAOF: what can happen TBH during the week-end [10:19] (low chance though) [10:19] RAOF: can you bump the build-dep? [10:19] that way, we'll be sure that we'll need a new Mir version [10:19] (even if it's artificial) [10:19] wdyt? [10:19] I could do that, I guess? [10:20] Actually - unity-system-compositor *does* have auto tests, right? [10:20] The bug only occurs under u-s-c, and is highly likely to be caught by *any* u-s-c testing [10:21] RAOF: those tests are integration tests [10:21] RAOF: they can't run autopilot [10:22] So those tests aren't run before promotion from -proposed? [10:22] RAOF: exactly [10:24] Ok; build-dep bump it is. [10:26] Fire in the hole! === hikiko is now known as hikiko|lunch [10:51] Is there still two cursors? [10:52] Nope. [10:53] So, now that everything's uploaded to proposed, time to disappear for the weekend. [10:53] What could possibly go wrong! [11:10] RAOF, ping === hikiko|lunch is now known as hikiko === om26er is now known as om26er|internet_ === om26er|internet_ is now known as om26er === alan_g is now known as alan_g|lunch [12:55] alf__, you are working on a patch for alt+ctrl+backspace in the examples? [12:56] robert_ancell: yes [12:56] alf__, ok, I was working on that too - I'll stop then [12:56] robert_ancell: basically, your branch adapted to mir::examples::ServerConfiguration [12:57] alf__, ok [12:57] alf__, I just rebased so it uses mir::examples::ServerConfiguration, but I didn't remove the duplication yet [12:58] robert_ancell: well, then you are farther ahead than I am :) [12:58] I was stuck on std::initializer_list - how to have one build in filter in the config but also support other filters that the examples require [12:58] built in filter rather [12:59] robert_ancell: yes, we need to get rid of initializer_list and replace it with a mutable container (e.g. vector) or perhaps some other abstraction [12:59] yes :) [13:00] alf__, ok, should I stop and leave you to make the merge then? [13:01] robert_ancell: I am not sure now, since you are further ahead than I am. I just declared intention of doing it, haven't really started yet [13:01] alf__, ok, I'll continue then - I'll be off on Monday after I fly back from IOM so feel free to finish it off if you have plans there [13:02] robert_ancell: ok, sounds good then [13:17] racarr: any progress with the stress test / thread race fix? === alan_g|lunch is now known as alan_g [14:23] hikiko: how are you doing? [14:24] alan_g, [14:24] I did it [14:25] it wasn't that simple [14:25] I had to overload * as well [14:25] to keep using the same methods [14:25] but it seems to work :D [14:25] I am testing and I will push in a moment [14:26] Cool, I have an automated test for it: lp:~alan-griffiths/mir/sketch-for-nested-mir-tests [14:27] thanks a lot! :D I will merge it [14:27] you merge that and run bin/acceptance-tests --gtest_filter=TestNestedMir* === jono is now known as Guest51067 [14:44] alan_g, I got some ok and passed [14:44] can I push the merge? [14:44] hikiko: please do === alan_g is now known as alan_g|EOW === ogra_ is now known as _ogra_ === _ogra_ is now known as ogra_ [18:43] :( just merged trunk in to client focus notifications again and lots of test failures [18:49] trunk looks ok to me (rev920), aside from the already known problem tests [18:53] kdub_: Yeah its just some weird interaction [18:53] probably having to do ith some redone test fixture and stubs vs mocks and blabla bla still investigating [18:53] its kind of cryptical somehow [18:53] broken pipe, connection refused, etc. [19:01] The thing is ApplicationMediatorReport session_connect and session_create_surface fail [19:01] but, session_disconnect [19:01] which contains session_create_surface as a literal textual subset [19:01] passes [19:01] I think something funny is going on with test_protobuf_client [19:07] maybe the event sink is trying to send events after the client has already destroyed it's surface [19:07] i.e. done->Run(); client destroys surface quickly [19:07] err [19:07] client disconnects [19:07] then the event sink is unclogged [19:07] and the socket is invalid [19:07] and I guess [19:07] an exception isnt being handled [19:07] due to some unrelated change [19:13] nah keeping the client alive doesnt fixit so its somethingelse [19:18] it may be happening when trying to send the focus lost message on close_session [19:18] need to investigate the ownership of the MessageSender [19:19] i.e. perhaps EventSender can not take a strong reference === Cimi_ is now known as Cimi [19:25] I see. It can only happen in the ~SessionMediator Session closed without disconnect code path [19:25] and even then only sometimes [19:30] so, it seems like the client process finishes succesfully [19:31] and dies without disconnect then the server gets sigterm by the testing process manager [19:31] and shuts down, ~SessionMediator is reached [19:31] which sees that disconnect was never called and calls SessionManager->close_session... [19:32] so, then SessionManager::close_session tries to clear the focus [19:32] the client which is being closed now, never closed it's surface either [19:32] so, the focus mechanism sees that said surface last had focus [19:32] and delivers an unfocused event [19:33] eventually ending in SocketMessenger throwing because of broken pipe [19:33] Almost surely, event_sender taking a weak reference to the message sender will fix it [19:33] but im concerned in that I do not understand why it didn't happen before [19:33] kdub_: Any ideas perhaps? [19:36] hmm [19:37] so a client is outliving the server? [19:38] kdub_: No, the client is shutting don, without calling disconnect or release_surface [19:38] so then the testing_process_manager kills the server [19:38] and in ~SessionMediator when close_session is called [19:38] eventually the surface is unfocused [19:38] causing things to try and send an event over the wire [19:38] and unhandled broken pipe exception [19:42] i'd hope there's a better way handle that than a proxy [19:43] havent thought too deply though how yet [19:43] kdub_: Mm. there are a bunch of ways to make the test pass but it feels like [19:43] something is wrong [19:43] kdub_: One thing is I think [19:44] EventSender can take std::weak_ptr perhaps? [19:46] i suppose [19:46] but it seems [19:46] that was the proxying though [19:46] also not correct XD [19:46] yeah [19:48] kdub_: This is a total diversion but I saw a crazy idea yesterday from john carmack on handling mutable state in multithreaded C++ game logic [19:49] first, you use a seperate garbage collected heap for all your mutable data i.e. your non asset data. [19:49] and basically you write all your code, kind of in the style we are using for multithreading except with two crazy differences [19:50] 1. Rather than any of your actors or whatever actually updating state, they return partially applied functions to do such, and then the main frame loop [19:50] sorts out how to apply such [19:50] but then the also clever bit is [19:51] well how do you actually enforce this, if you are handing out pointers still [19:51] so the objects can look at eachother [19:51] so the idea is during the garbage collection step (which you do every frame), you copy the entire mutable heap [19:51] and all your objects that have pointers to other objects [19:52] you update with a pointer to the heap from the last frame [19:52] which you then mprotect [19:52] so basically each of your actors, can have "real" enforced purity [19:52] and you have a small bit of monadic code that applies all these unctions they create [19:52] :p not really an architecture for mir but I thought it was really fascinating [20:54] Back from lunch, Ill produce a reduced test case. so this doesn't muddle client focus notifications [20:55] i.e....events_sent_during_disconnect_do_not_crash_server [21:30] got a reduced test but the ownership doesnt work like I thought it did so just weak_ptr isnt enough [21:53] * kdub_ forgot to mention... if i go dark, its because the internet company cut me off early [21:53] transferring my service over the weekend [22:15] the connected sessions abstraction is making this hard to solve [22:27] sigh I tried having the EventSender used connected_sessions to verify that [22:27] the session was still around [22:27] but this whole process of disconnect happens during the [22:28] connected_sessions.remove call [22:28] so of course that is a deadlock [22:29] part of the reason this code is so difficult is socket session killing itself [22:29] by calling connected_sessions.remove