I think I've found something. I noticed that when I try to launch apps from ssh, this usually works, but after running ubuntu_test_cases.memory_usage_measurement this fails with
$ gallery-app
[...]
(process:4913): GLib-GIO-CRITICAL **: g_dbus_connection_register_object: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
[...]
** (process:4913): ERROR **: Unable to get session bus: Could not connect: Connection refused
This is because running memory_usage_measurement crashes the whole existing session, and after that the session d-bus, unity8, and everythign else gets restarted. That means that in an existing process $DBUS_SESSION_BUS_ADDRESS is now invalid, and (in my case) I have to log out and back in. If something similar happens in the tests that means that their test session bus that they started will become invalid when it crashes. Javier, can you please verify the identity (pid/startup time) of the session dbus-daemon when you run your tests?
I think I've found something. I noticed that when I try to launch apps from ssh, this usually works, but after running ubuntu_ test_cases. memory_ usage_measureme nt this fails with
$ gallery-app connection_ register_ object: assertion 'G_IS_DBUS_ CONNECTION (connection)' failed
[...]
(process:4913): GLib-GIO-CRITICAL **: g_dbus_
[...]
** (process:4913): ERROR **: Unable to get session bus: Could not connect: Connection refused
This is because running memory_ usage_measureme nt crashes the whole existing session, and after that the session d-bus, unity8, and everythign else gets restarted. That means that in an existing process $DBUS_SESSION_ BUS_ADDRESS is now invalid, and (in my case) I have to log out and back in. If something similar happens in the tests that means that their test session bus that they started will become invalid when it crashes. Javier, can you please verify the identity (pid/startup time) of the session dbus-daemon when you run your tests?