| robert_ancell | thomi, RAOF, it appears the hang is due to a bunch of dmabuf fds being left open - seen that before? | 03:00 |
|---|---|---|
| thomi | sounds similar to the last problem I had, buton the server side? | 03:01 |
| robert_ancell | thomi, yeah | 03:01 |
| RAOF | Oh, this is server side? We test that they get closed client-side. | 03:01 |
| robert_ancell | RAOF, yeah, see bug 1185183 | 03:02 |
| ubot5 | bug 1185183 in Mir "mir_demo_server hangs" [High,Triaged] https://launchpad.net/bugs/1185183 | 03:02 |
| robert_ancell | RAOF, where does the dmabuf stuff live in the codebase? Grep is not showing it - is it called something else? | 03:04 |
| RAOF | robert_ancell: Yeah, grepping for "prime" should show it. | 03:09 |
| robert_ancell | RAOF, ta | 03:09 |
| robert_ancell | RAOF, which test are you referring to that checks the file descriptors for the client? | 03:31 |
| robert_ancell | oh, appears to be tests/unit-tests/client/gbm/test_gbm_client_buffer.cpp | 03:34 |
| RAOF | robert_ancell: Correct. (Sorry for the delay, saucy might not be entirely stable today) | 04:31 |
| robert_ancell | I'm on saucy... could be impending doom for me? | 04:32 |
| RAOF | Maybe if you've got two monitors. | 04:37 |
| RAOF | (My system seems to like hangingish (possibly) when I've got two monitors enabled) | 04:37 |
| thomi | hmmm, I'm on saucy with two monitors (sometimes three), and I haven't noticed anything today... | 05:00 |
| robert_ancell | RAOF, btw, do we have to revert the drm magic change? | 05:01 |
| RAOF | Yes | 05:01 |
| robert_ancell | :( | 05:01 |
| robert_ancell | no way around it? | 05:01 |
| RAOF | Not without fairly invasive patches. | 05:02 |
| RAOF | ie: we *could* add a MIR-DRI protocol to X that hands out drm fds, implement the mesa side, and have apps use that. | 05:03 |
| RAOF | This seems like an awful lot of work when we could just have the drm magic API. | 05:04 |
| alf__ | alan_g: any thoughts on/objections to moving rpc related code in client to client/rpc and mir::client::rpc namespace? | 09:07 |
| alan_g | alf__: the client code has grown enough to need splitting into separate concerns. | 09:16 |
| alf__ | alan_g: Agreed | 09:17 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| === mmrazik is now known as mmrazik|lunch | ||
| alf__ | hikiko: @mir.fix-missing-virtual-destructors, the branch failed CI... (the unwritten rule is that you won't get any reviews until your branch passes CI) | 10:34 |
| alf__ | hikiko: just a heads up :) | 10:34 |
| hikiko | :s | 10:41 |
| alan_g | alf__: lttng problems? https://code.launchpad.net/~robertcarr/mir/input-lttng/+merge/166123/comments/368258 | 10:41 |
| hikiko | I compiled it | 10:41 |
| hikiko | :s | 10:41 |
| hikiko | I just put back the destr. and removed the headers you told me nothing else | 10:42 |
| hikiko | let me check again | 10:42 |
| * alan_g thinks http://www.codinghorror.com/blog/2007/03/the-works-on-my-machine-certification-program.html | 10:42 | |
| hikiko | alf__, what is the error you get? | 10:44 |
| hikiko | i recompiled and got no failure | 10:45 |
| alf__ | alan_g: @lttng, no, that's normal, if you use the lttng library with a program that uses forks etc you also need to LD_PRELOAD=liblttng-ust-fork.so. I don't think that's the problem racarr is having though, I think he just needs to ld_preload the mir tracepoint provider. | 10:45 |
| alf__ | hikiko: check the failure logs from the MP | 10:46 |
| alan_g | alf__: thanks - I misremembered the incantation. (and HACKING didn't help) | 10:47 |
| === tvoss is now known as tvoss|afk | ||
| === mmrazik|lunch is now known as mmrazik | ||
| alf__ | mmrazik: Can we upgrade our VM CI builds to use raring? They are failing because they pull an old lttng-ust version with headers that have compilation problems with C++. | 11:03 |
| mmrazik | mhm... still building on quantal? | 11:03 |
| mmrazik | alf__: I'm on it | 11:03 |
| alf__ | mmrazik: great, thanks | 11:03 |
| alf__ | mmrazik: (probably VM autolanding, too) | 11:04 |
| === alan_g is now known as alan_g|afk | ||
| mmrazik | alf__: done. I triggered a test build to see | 11:06 |
| alf__ | mmrazik: thanks | 11:06 |
| === alan_g|afk is now known as alan_g | ||
| === tvoss|afk is now known as tvoss | ||
| === alan_g is now known as alan_g|lunch | ||
| === mmrazik is now known as mmrazik|afk | ||
| kgunn | reboot to saucy (i hope) | 12:59 |
| === alan_g|lunch is now known as alan_g | ||
| === mmrazik|afk is now known as mmrazik | ||
| racarr | Morning | 13:50 |
| alan_g | Afternoon | 13:52 |
| === mzanetti is now known as mzanetti|food | ||
| === mzanetti|food is now known as mzanetti | ||
| racarr | comments on input-lttng :) thanks for pointing out LD_PRELOAD alf/alan | 14:18 |
| racarr | neat stuff | 14:18 |
| racarr | alan_g: What do you mean by "These don't gain by being inline" in reference eto d'tors in rebuild-input-targeting | 14:27 |
| racarr | do they gain by being in implementation file? | 14:27 |
| alf__ | racarr: Yes, pretty cool. Soon (by EOW) we should have client side tracepoints, too, so we will be able to get some very interesting measurements for both input and rpc. | 14:28 |
| alan_g | racarr: with an inline function the compiler needs to be ready to instantiate it in any TU that compiles the header. With it out of line it knows it only has to instantiate it in one TU. | 14:30 |
| racarr | alf__: Excellent! | 14:30 |
| alan_g | So, unless there is a reason to have functions inline, we put them out of line. | 14:30 |
| racarr | alan_g: Hmm. ok | 14:30 |
| alan_g | racarr: I just mean there's no reason for them to be inline. | 14:31 |
| racarr | mm | 14:31 |
| racarr | alan_g: Pushed some updates on rebuild-input-targeting | 14:33 |
| racarr | share your fear about maybe we are breaking things now ;) | 14:33 |
| racarr | this one is pretty simple...and we have some acceptance tests...but uh...I dunno | 14:34 |
| racarr | I want lots more input acceptance tests | 14:34 |
| racarr | test_client_input.cpp is a little precarious now so I think once this branch lands I am going to spend some time | 14:34 |
| racarr | making a new InputTestFixture or something | 14:34 |
| racarr | and hopefully getting lots of input scenarios under test | 14:34 |
| alan_g | racarr: that should improve our confidence | 14:35 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| kdub | good morning, status, going to take another cleanup pass at the buffer swapper switcher algorithm, then mp. after that, maybe some performance measurements and writing an ipc message to signal performance hints to the server (like swapinterval 1/0, composition bypass) | 15:01 |
| alf__ | status: refactoring client code to accommodate lttng reporting (and improve the client code in general) | 15:05 |
| kdub | alf__, yay :) | 15:05 |
| alf__ | all: Enjoy the rest of your day! | 15:07 |
| mzanetti | alf__: you too | 15:07 |
| mzanetti | :) | 15:07 |
| alf__ | :) | 15:08 |
| === mmrazik is now known as mmrazik|afk | ||
| racarr | Trying to find something for myself to do that doesn't conflict with my existing branches >< | 16:15 |
| racarr | I guess the blueprints say I am going to do client focus notifications before June so I can do that...it only conflicts a little | 16:16 |
| racarr | is focus a surface attribute? | 16:19 |
| racarr | seems correct on the client side but incorrect on the server side | 16:19 |
| alan_g | racarr: are you starting the "attribute" vs "association" discussion again? | 16:24 |
| racarr | alan_g: Not exactly. | 16:28 |
| racarr | alan_g: In this case I am wondering, in a more literal sense whether to model focus as a MirSurfaceAttribute | 16:28 |
| racarr | but I guess it is that discussion | 16:29 |
| racarr | in the current architecture to there is no clear way to deliver the "focus lost" events to the correct surface. | 16:29 |
| racarr | So I am exploring refactorings, and it comes down to...(I think so far) to either | 16:30 |
| racarr | Focus becomes some sort of surface attribute (a MirSurfaceAttribute, some sort of token that is moved around, something) | 16:30 |
| racarr | or start tracking surface focus in what is now the session manager, which I would try and split in to like | 16:30 |
| racarr | SessionManager->SessionStore, FocusArbitrator(Assosciator?) | 16:31 |
| racarr | I mean, two objects, not some sort of inheritance there | 16:31 |
| racarr | I'm also hung up on MirSurfaceEvent being part of MirEvent :p | 16:32 |
| alan_g | How are you hung up? | 16:32 |
| racarr | Trying to decide, how I want to model the event...and it doesn't really fit (unless it becomes a surface attribute) | 16:32 |
| racarr | the way I wanted to do it was | 16:32 |
| racarr | the old MirEventDelegate | 16:32 |
| racarr | in addition to handle_event like it has now | 16:32 |
| racarr | err like it had before it was removed | 16:33 |
| racarr | would have grown methods like focus_received, focus_lost | 16:33 |
| racarr | attribute_changed, etc. | 16:34 |
| racarr | rather than an increasingly intricate MirEvent structure | 16:34 |
| alan_g | racarr: it is *soft*ware - you can change it if it doesn't fit current needs | 16:35 |
| racarr | Hehe. I know. | 16:35 |
| racarr | I am just trying to figure out the boundary between my needs, and | 16:35 |
| racarr | my attachment to certain aesthetics | 16:35 |
| racarr | well strictly in this situation, I don't have any needs, the requirements do :p | 16:35 |
| racarr | i.e. while I think it's clearer in my head through these focus_received/focus_lost delegates...that might just be because ive explored that model more | 16:36 |
| alan_g | racarr: there are 20min to EOD - you can drag me into a discussion or let me review your MPs. Your choice. | 16:37 |
| racarr | alan_g: Please ignore me | 16:38 |
| racarr | XD | 16:38 |
| racarr | thanks for reviewing :) | 16:38 |
| racarr | sorry to be kind of scattered, just having trouble focusing (...*cymbal crash*) today. | 16:38 |
| alan_g | racarr: np - you can review my trivial tidy-up MPs when your focus gets lost. | 16:46 |
| racarr | Ill check them out | 16:50 |
| === alan_g is now known as alan_g|dance | ||
| racarr | Got some failing acceptance tests for client side focus notification. Lunch time! | 18:22 |
| racarr | Back | 19:17 |
| racarr | Hmm ok half got client focus notifications working, finished the tests...the implementation difficulty | 20:09 |
| racarr | is calling surface->configure before the SessionMediator::create_surface has returned | 20:09 |
| racarr | is a magnificent failure | 20:09 |
| racarr | i.e. an event is sent to the client for a surface which it has not yet been informed has been created | 20:09 |
| racarr | so I think I will need to create an EventSink which | 20:10 |
| racarr | can buffer event streams or some such | 20:10 |
| racarr | hold event streams until ready? | 20:10 |
| kdub_ | racarr, sounds kinda like | 20:11 |
| kdub_ | our surface creation mechanism needs some rework then | 20:11 |
| kdub_ | not sure how complicated that is ^_^ | 20:12 |
| kdub_ | i get lost in the weeds of mf::Surface, msh::Surface and ms::Surface sometimes too | 20:12 |
| racarr | Mm... *thinking cap* | 20:19 |
| * kdub_ keeps finding ways to improve the SwapperSwitcher | 20:22 | |
| racarr | hmm | 20:29 |
| racarr | it's pretty easy to wrap the EventSink in SessionMediator | 20:29 |
| racarr | with something that delays until the surface has been created | 20:29 |
| racarr | but then that lives there...forever -.- | 20:30 |
| racarr | and you can futz with the interfaces some so it can rewire itself out or something but it just seems wrong. | 20:30 |
| racarr | I guess first there is a bit of a design decision | 20:31 |
| racarr | if a surface is created and focused when created | 20:31 |
| racarr | do you receive a focused event? | 20:31 |
| racarr | My initial thought was yes but it may be possible to simplify if no | 20:31 |
| racarr | ...I guess | 20:34 |
| racarr | if a branch + a virtual function call is really an overhead in surface attribute changing IPC notification | 20:35 |
| racarr | someone can come back and find a different solution :p | 20:35 |
| racarr | "CloggedEventSink" I'm pretty happy about that | 20:37 |
| robert_ancell | thomi, tests working now? | 21:03 |
| thomi | robert_ancell: will check | 21:17 |
| thomi | just finishing my morning firefighting rounds | 21:18 |
| kgunn | kdub_: ping | 21:23 |
| kdub_ | pong | 21:23 |
| racarr | If anyone has time would appreciate another review on at least the InputDispatcher.cpp part of https://code.launchpad.net/~robertcarr/mir/rebuild-input-targeting | 21:36 |
| thomi | robert_ancell: got a second? | 21:40 |
| robert_ancell | yep | 21:40 |
| thomi | robert_ancell: the single threaded stress test now works, but something in either allocating or deallocating surfaces is not thread safe, and causes the server to bork | 21:40 |
| robert_ancell | thomi, bug/test-case? | 21:40 |
| thomi | just filing it now :) | 21:41 |
| robert_ancell | I'll have a look at it | 21:41 |
| thomi | robert_ancell: the short version is to grab lp:~thomir/+junk/mir-stress ; build; run ./mir-stress -t 2 -n 10 | 21:41 |
| thomi | robert_ancell: bug filed: https://bugs.launchpad.net/mir/+bug/1185589 | 21:44 |
| ubot5 | Launchpad bug 1185589 in Mir "Mir server crahes when allocating & freeing surfaces from multiple threads" [Undecided,New] | 21:44 |
| robert_ancell | thomi, hmm, I just get the test prog blocking forever and no problems in the server - are you using Mir trunk or the latest package from the PPA? | 21:49 |
| racarr | thomi: It's worth ruling out with --enable-input=false | 21:50 |
| thomi | robert_ancell: latest from ppa | 21:50 |
| thomi | racarr: that's on the server, right? | 21:50 |
| robert_ancell | thomi, saucy or raring? | 21:50 |
| thomi | saucy | 21:51 |
| robert_ancell | racarr, have you noticed some input tests failing when you run ./native-compile.sh a second time? It appears there might be some data files left over from a previous run, but I can't seem to find them | 21:51 |
| thomi | racarr: still happens with --enable-input=false | 21:51 |
| thomi | robert_ancell: will try and get some stacktrace goodness for you | 21:52 |
| thomi | oh - mir_demo_server helpfully prints a stacktrace when it crashes | 21:52 |
| thomi | looks like it's a double-free | 21:53 |
| thomi | in mir::frontend::SessionMediator::create_surface | 21:53 |
| thomi | (that's me un-mangling the symbols in my head, so it might be a little off) | 21:53 |
| racarr | robert_ancell: No I haven't... which tests? There are no files used afaik | 21:55 |
| racarr | There are some weird things going on right now though. I see a weird intermittent build failure that I sometimes have to make clean for (something to do with DRM auth magic) | 21:56 |
| racarr | and acceptance tests spew "ERROR: Event parsed" | 21:56 |
| racarr | because somehow the client rpc report got switched to log by default or something | 21:56 |
| robert_ancell | racarr, I'll get a log now | 21:58 |
| robert_ancell | racarr, http://paste.ubuntu.com/5714864/ | 22:00 |
| robert_ancell | racarr, I'm *fairly* sure if I clean and rebuild it will work fine. This is lp:mir trunk | 22:00 |
| racarr | robert_ancell: Interesting | 22:04 |
| racarr | I will look in to it soon | 22:04 |
| racarr | no immediate ideas | 22:04 |
| robert_ancell | racarr, ok, ta | 22:04 |
| racarr | all the ERROR: Event parsed stuff is unrelated | 22:04 |
| racarr | and has to do with surface states | 22:04 |
| racarr | Almost finished with client focus notification... | 22:05 |
| racarr | working on testing the event stream blocking/unblocking in session mediator. | 22:05 |
| thomi | robert_ancell: crashes with lp:mir as well. For some reason gdb isn't playing ncely though | 22:13 |
| racarr | blah happy I made my acceptance test pass only to discover I am causing intermittent failures in BespokeDisplayServerTestFixture.server_can_shut_down_when_clients_are_blocked | 23:32 |
| racarr | hmm | 23:32 |
| * kdub_ is singing in my head "this is the branch that never ends" | 23:39 | |
| racarr | aha someone was sneaky in mfd::SocketSession ::send | 23:40 |
| racarr | whole_message is surprisingly not a locally scopped variable | 23:40 |
| racarr | and its a RACE | 23:41 |
| thomi | robert_ancell: I finally managed to get a sensible stack trace for you: https://launchpadlibrarian.net/141048607/gdb.txt | 23:49 |
| thomi | Is that illuminating at all? | 23:49 |
| thomi | actually, that one looks like it might be in the input handling stuff.. racarr ^^ | 23:51 |
| thomi | and yet it crashes if I disable input as well, I wonder if the stack is the same | 23:51 |
| thomi | racarr: I think I must have mis-typed earlier, it seems it doesn't crash when I disable the input system | 23:53 |
| racarr | thomi: Oh that's good I was hoping it was my fault. | 23:56 |
| thomi | errr... ok | 23:56 |
| thomi | seems kind of masochistic, but OK | 23:56 |
| racarr | thomi: Ok that's either | 23:56 |
| racarr | well | 23:57 |
| racarr | it's either corruption somewhere else | 23:57 |
| racarr | or...fd exhaustion? | 23:57 |
| racarr | because this is about | 23:57 |
| racarr | socketpair failing | 23:57 |
| thomi | it is? | 23:57 |
| thomi | I didn't look up the failing assertion yet | 23:57 |
| racarr | thomi: Check out 3rd_party/android-input/android/frameworks/base/services/input/InputTransport.cpp | 23:58 |
| racarr | ok so it's not socketpair failing. | 23:58 |
| racarr | its the fcntl O_NONBLOCK | 23:58 |
| racarr | failing | 23:59 |
| racarr | Ok | 23:59 |
| racarr | I think I know what it is | 23:59 |
| thomi | oh? | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!