unity8 crashed with what(): Requesting handle for an unregistered channel

[Michał Sawicz]

Every once in a while on current image + proposed (Qt 5.2 is in there), unity8 crashes on exit with:

terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::logic_error> >'
  what(): Requesting handle for an unregistered channel

ProblemType: Crash
DistroRelease: Ubuntu 14.04
Package: unity8 7.84+14.04.20140307-0ubuntu1 [modified: usr/share/upstart/sessions/unity8.conf]
Uname: Linux 3.4.0-5-mako armv7l
ApportVersion: 2.13.3-0ubuntu1
Architecture: armhf
CurrentDesktop: Unity
Date: Fri Mar 14 12:07:08 2014
ExecutablePath: /usr/bin/unity8
ExecutableTimestamp: 1394191081
InstallationDate: Installed on 2014-03-14 (0 days ago)
InstallationMedia: Ubuntu Trusty Tahr (development branch) - armhf (20140314)
ProcCmdline: unity8
ProcCwd: /home/phablet
Signal: 6
SourcePackage: unity8
StacktraceTop:
 __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
 ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
Title: unity8 crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm autopilot cdrom dialout dip nopasswdlogin plugdev sudo tty video

[Apport retracing service (apport)]

StacktraceTop:
 __libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44
 raise () from /tmp/apport_sandbox_sr0qBJ/lib/arm-linux-gnueabihf/libc.so.6
 abort () from /tmp/apport_sandbox_sr0qBJ/lib/arm-linux-gnueabihf/libc.so.6
 __gnu_cxx::__verbose_terminate_handler() () from /tmp/apport_sandbox_sr0qBJ/usr/lib/arm-linux-gnueabihf/libstdc++.so.6
 ?? () from /tmp/apport_sandbox_sr0qBJ/usr/lib/arm-linux-gnueabihf/libstdc++.so.6

[Daniel van Vugt (vanvugt)]

Although the stack traces are strangely unhelpful, the offending exception only exists in one place in the Mir source:

src/server/input/android/android_input_registrar.cpp: BOOST_THROW_EXCEPTION(std::logic_error("Requesting handle for an unregistered channel"));

[Alexandros Frantzis (afrantzis)]

Have we seen this recently?

[Robert Carr (robertcarr)]

I propose that this was fixed in r157 onJuly 2nd.

Let's look at how the exception could occur, follow along with grep at home for fun:

Starting with just the mir tree:

1. The exception can only occur in the InputRegistrar::handle_for_channel (android_input_registrar.cpp).
2. handle_for_channel is only invoked from the InputTargetEnumerator and the InputTargeter.

Let's break things down to find the cause of the exception

0. We can see QtMir does not directly use handle_for_channel
1. The InputTargetEnumerator, this is only used by the InputDispatcher. Of course, in qtmir the InputDispatcher is replaced with the QtEventFeeder, so it can not be Mir's usage of the InputTargetEnumerator triggering the exception. We can see the QtMir tree does not directly use the InputTargetEnumerator either, so we can rule it out as the cause of the exception.
2. The InputTargeter is the remaining culprit and its only used by the shell focus setter.

If we dig in to QtMir though we see
1. The InputTargeter is not used directly
2. The shell focus setter is overriden with a noop

By this logic we have shown that handle_for_channel is never called in QtMir (and why would it be? It's purely used to translate between InputDispatcher android types and MirSurfaces to avoid leaking the android input window interface in to the Mir surface interface...as the InputDispatcher is eliminated this code should be as well). However clearly this exception was observed at one point so we must provide an explanation:

bzr blame focussetter.cpp draws our attention to revision 157 (I suggest skimming bzr diff 156..157 as the committ message is a little misleading). We can see prior to r157 QtMir was not overriding the shell focus setter and making use of the default mir impl, thusly making use of the InputTargeter. We can also see application_manager.cpp making direct use of the_focus_controller()->set_focus_to( thus invoking the input targeter. One feasible explanation for the race is that depending on the ordering of observer registration the application manager may be notified surface removal after the input registrar has processed them.

None-the-less I am satisfied that this code path is no longer active and thus closing the bug as fix released.