Deadlock in Unity8

[Cemil Azizoglu]

Got a lockup on boot, here's a another gdb "t a a bt".

[Alberto Aguirre (albaguirre)]

This doesn't seem related to mir code - it looks more like a flaw with Qt DBus/QMutex .

From the gdb dump, Thread 11 is waiting on a Qt signal to be dispatched (BlockedQueuedConnection), so an event is posted to the main thread (Thread #1) which should signal the semaphore given.

Thread 1 seems to be responding to a DBus event waiting on a mutex lock through syscall(__NR_futex, FUTEX_WAIT,....)

It's not apparent from the gdb dump why Thread #1 is stuck there.

[Gerry Boland (gerboland)]

I agree with Alberto's assessment. Qt's mainloop appears blocked. Would need more frames of thread1 to get a good idea why.

[Michał Sawicz (saviq)]

Forgot to get libdbus symbols :/, will do so the next time I encounter this.

[Daniel van Vugt (vanvugt)]

The offending code that's blocking is in QtMir:

--- QTMIR ---
Thread 11 (Thread 0xae5ff450 (LWP 2627)):
...
#6 0xffffffff in SessionAuthorizer::requestAuthorizationForSession(unsigned long long const&, bool&) () at /usr/lib/arm-linux-gnueabihf/qt5/plugins/platforms/libqpa-mirserver.so
#7 0xffffffff in SessionAuthorizer::connection_is_allowed(mir::frontend::SessionCredentials const&) () at /usr/lib/arm-linux-gnueabihf/qt5/plugins/platforms/libqpa-mirserver.so
--- MIR ---
#8 0xffffffff in mir::frontend::ProtobufConnectionCreator::create_connection_for(std::shared_ptr<boost::asio::basic_stream_socket<boost::asio::local::stream_protocol, boost::asio::stream_socket_service<boost::asio::local::stream_protocol> > > const&, mir::frontend::ConnectionContext const&) (this=0xb047c594, socket=std::shared_ptr (count 2, weak 0) 0x75a9f4, connection_context=...) at /build/buildd/mir-0.11.0+15.04.20150209.1/src/server/frontend/protobuf_connection_creator.cpp:65

[Gerry Boland (gerboland)]

Please read previous comments before re-assigning affected project. Unity8's main loop is blocked, which will cause qtmir to block mir when mir is asking if a session should be authorized or not - as that decision made in unity8's main loop.

[Alberto Aguirre (albaguirre)]

Right Thread #1 would be the one that would unblock Thread #11; it's not clear why Thread #1 is stuck waiting for that futex to signal.

An inspection of the code involved does NOT reveal possible mutex locking order issues (as far as I can see). Perhaps more inspection around that DBUs debug dispatch mutex would reveal the issue.

[Albert Astals Cid (aacid)]

How reproduceable is this? It'd be cool if you can install dbus debug symbols so that thread 1 backtrace continues