On 13 February 2018 at 17:46, Daniel Stone <dan...@fooishbar.org> wrote: > Hi Emil, > > On 13 February 2018 at 16:37, Emil Velikov <emil.l.veli...@gmail.com> wrote: >> The following two questions come to mind: >> - app bugs - using threads? ivi-shell-user-interface.c mentions >> pthread, but haven't looked closely > > Hm, I couldn't find any threading-related bugs at all: everything I > found was clear just looking at the inter-process flows. Did you have > anything in particular in mind? > >> - missing dependencies > > Again, did you have anything in particular in mind? Looking at the > logs, it loads the exact same set of plugins/helpers/configs in both > cases (working/broken). Dumping out /proc/self/smaps didn't show any > discrepancies either. Everything was fresh and up-to-date: it's seems > like it's only the test execution environment which influences this. > >> Having a look reveals: >> - extremely convoluted test runner > > Sure. We had a few requirements which led to the runner being the way > it was, mainly based on it being relatively easy to write tests, and > assertion failures / segfaults not destroying the whole testsuite. > Personally I like igt, and I guess others like gtest or maybe Piglit, > but none of them are anything like simple. Do you have a good > replacement in mind? > > (Whilst we're mentioning test runners and threads, I really wouldn't > mind one which ran everything in threads rather than forking > children.) > >> - dummy BACKEND variable - always headless-backend.so > > It's not a dummy: you can run 'make check BACKEND=foo-backend.so' as a > developer, if you'd like to test a particular backend. Most of them > are totally unsuitable for general-purpose use (e.g. wayland-backend > or x11-backend will pop up a billion windows as it goes about its > work, and that rapid de/focus can in fact break some tests), so we > default to headless-backend for mere mortals. But it is there as an > option for people who know what they're doing, or want to try tests in > a different context. > >> - the --backend, --config, --shell and/or --modules file is not part >> of the respective dependency chain > > The checks here are only run as part of the 'check' target; check > depends on check-am, which in turn depends on the all-am target, which > in turn depends on all libraries/programs/built-sources, which covers > all of the items you've mentioned. Is there some subtlety I'm missing > here? > Pardon for the delay, Dan. While Emre has already resolved the issue, let me add a couple words more to my earlier, cryptic, email:
- threading I could not spot any, although the behaviour that you described sounded like an in-weston race condition. We now know that wasn't a race, but a layering confusion/violation(?). - missing dependencies [in the Makefile.am] I didn't explicitly check if all the files (binaries and configs) are correctly annotated, hence present before the tests were run. On the testrunner side - I've used cmocka and it seemed rather nice. I liked the exception handling for signals, it has no templates plus valgrind was always happy. HTH Emil [1] https://api.cmocka.org/ _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel