Leapd hangs during stratup under linux

[AndreasG]

Hello everyone,

I am currently using debian testing. Somewhere during the last days leap stopped working, i.e. it prevented my OS from shutting down.

I turns out that leapd hangs during startup with the message:

[Info] WebSocket server started
[Info] Secure WebSocket server started

The only way to kill the application is using SIGKILL. I had a quick look using gdb:

which said:

Thread 1 "leapd" received signal SIGINT, Interrupt.
0x00007ffff70c6b26 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x1089198) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
88      ../sysdeps/unix/sysv/linux/futex-internal.h: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0x00007ffff70c6b26 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x1089198) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x1089148, cond=0x1089170) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x1089170, mutex=0x1089148) at pthread_cond_wait.c:655
#3  0x00007ffff6deebac in std::condition_variable::wait(std::unique_lock<std::mutex>&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x0000000000481dda in ?? ()
#5  0x0000000000445ff6 in ?? ()
#6  0x00000000004213bc in ?? ()
#7  0x00007ffff648d561 in __libc_start_main (main=0x421280, argc=1, argv=0x7fffffffdc48, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdc38) at ../csu/libc-start.c:297
#8  0x0000000000445d93 in ?? ()

To me this looks like a deadlock.

However, I suppose someone of the Linux developers might be interested in that. Would be nice to have a fix. What ever broke the current SDK, it might be part of upcoming ubuntu distributions.

Best,

Andreas

[jhung]

Thanks for letting us know. I've contacted our engineering team to look into this

[jdonald]

This is Debian 9 Stretch? Unfortunately we haven't done any testing there, given the last time we did a Linux release was in the days of Debian 8 Wheezy, plus V2 only officially supported Ubuntu.

I'm not so sure the stack trace represents a deadlock, given that even in normal operation if you interrupt it and check out the various threads with info threads, surely some of them will be waiting on std::condition_variable::wait(). One way to tell if it's truly deadlocked would be to connect a client like Sample from the SDK. Even when there's no device, if the service is active it can connect to the service via a socket.

If it still responds on the socket, you could also check whether it detects your device when plugged in. You can use either the systemctl log or the GUI log in LeapControlPanel.

In the past it was possible to get leapd into a state that it was hard to kill, but that usually involved at least connecting a device. Does your hang on exit happen even when there is no Leap Motion Controller connected to the machine?

[AndreasG]

This is Debian 9 Stretch? Unfortunately we haven't done any testing there, given the last time we did a Linux release was in the days of Debian 8 Wheezy,

Actually I am using Buster, which is even ahead of Stretch.

plus V2 only officially supported Ubuntu.

I know. I don't expect any support here, but I thought it might be interesting for you, and I am still happy about any help .

If it still responds on the socket, you could also check whether it detects your device when plugged in. You can use either the systemctl log or the GUI log in LeapControlPanel.

I tried to start the leapd from commandline, and attach the LeapMotion. You where right, the LeapMotion is detected.

[Info] WebSocket server started
[Info] Secure WebSocket server started
[Info] Leap Motion Controller detected: LP43516768423
[Info] Firmware is up to date. 
Failed to parse a message from a zero-copy input stream
Failed to parse a message from a zero-copy input stream

However, using the Visualiser there is no signal shown. Usually the LeapMotion gets some red lights when connecting, which didn't happen. Stopping via Ctrl^C didn't work as well. The LeapControlPanel seem the recognise the Ctrl^C, as it claims that there is no daemon running any more.

Does your hang on exit happen even when there is no Leap Motion Controller connected to the machine?

That's how I discovered the bug. I had leapd running per default, together with the small linux uinput driver I wrote. Usually I hadn't connected any device. When I tried to shutdown the system leapd blocked the entire shutdown, till systemd finally decided to kill it using SIGKILL.

Hope that helps.

Best,

Andreas

[withaar]

I am having the same problem, on ubuntu 18.04. I am also using a uinput driver I am redeveloping at the moment. Any progress?

I find that "sometimes" I can get it to work in the visualizer, after e.g. running the diagnostics from the LeapControlPanel.

It would be absolutely lovely to get back some rudimentary support. All I am using is the location and direction of the fingers.

[withaar]

I am selling my leap - it is just eating up time. There is no reasonable expectation even the v2 sdk getting a maintenance release.

[jhung]

Sorry to hear that withaar. Unfortunately, we do not have any plans on releasing updated software for the Linux platform at this time but I have forwarded the request on to our team.

[camdenbock]

@jhung Is there any way that the community could support a LleapMotion release of Orion for Linux?

My (small) team would be interested in contributing if there was a way to do so productively.

Our work is entirely Windows-based right now in order to support LeapMotion, but we would love to move to Linux if possible.

[jhung]

I've checked with our team and unfortunately, we are not able to do such a thing. You'll need to stay on the Windows platform for now.

[AndreasG]

I still see "Linux Support" on the Website for V2 [1][2]. Has there been any update, which fixes the issue?

[1] https://developer.leapmotion.com/setup/desktop
[2] Under "Software Versions" https://developer.leapmotion.com/documentation/