Closed jdonald closed 8 years ago
Could be an Autowiring defect, definitely requires further investigation.
@jdonald can you determine whether this issue is still present on 74798574b087f42a7a6fb57f37a2cf3533586821?
leapd with autowiring 7479857 hangs for me after 5 seconds on OS X, making this issue difficult to test. I'm still investigating whether this hang is actually due to autowiring's develop branch or something in my local environment.
Confirming this is fixed on the autowiring develop branch! I forced 10x flips in both directions and tracked a dummy hand for five minutes, yet the FlipChecker assertion has not shown up in the logs.
Ugh, I spoke too soon. Five more minutes, and the error appeared in the log.
[14:31:05] [Critical] Runtime error on Decorate(flipDecision), ignoring: Cannot decorate this packet with type FlipDecision, the requested decoration is already satisfied
[14:31:19] [Critical] Runtime error on Decorate(flipDecision), ignoring: Cannot decorate this packet with type FlipDecision, the requested decoration is already satisfied
I think this may be a downstream issue. I'm moving off of 0.7.3 so as to not block the release. I will diagnose and, if the fix needs to be made here, I'll cut a 0.7.4 hotfix.
Mimesis is also seeing this on Linux. Not sure why this happens so often on OS X and Linux but not Windows.
FYI, I have tested locally and this is not fixed on the latest develop / 0.7.4 candidate.
Ok. This might be a race condition, will require further investigation.
I think #866 may have addressed this one.
The packet decoration code that required this workaround was removed in leapmotion/platform#5096 (ref-recomb-part5), so this is no longer reproducible.
Hi, Do you have this fix for Linux SDK?
For autowiring? That was fixed in the issue that @codemercenary linked above and thus the Linux version of autowiring 1.0.3.
Or are you referring to the Leap SDK? If so, at least the workaround (Runtime error on Decorate(flipDecision), ignoring
) ought to be present in the Linux hotfix: https://community.leapmotion.com/t/linux-support-situation/4523
Hopefully you're using the download from the box folder on that forum post, and not he broken one from https://developer.leapmotion.com/sdk/v2/ ?
Thank you!
The hotfix works, but unfortunately, it has some issues with launching on Ubuntu 16.04. When I reboot the operation system 2/5 times leap motion driver will not initiate correctly and even IR lights on the device will be down.
Here are some details from our system architect: "DIAGNOSIS: I have 100% confirmed there is a race condition inside of the driver upon start up. The driver does several things on startup, but there's two in particular that we care about:
(1) It restarts the Leap USB connection socket. (2) It initiates a server that provides a websocket to allow communication with the Leap USB device.
(1) MUST FINISH BEFORE (2), when that fails to happen then the Leap system is unresponsive.
This was hard to track down because the logs for each process are aggregated separately in different unrelated locations. It was only when I combined the logs and sorted them by the timestamps when I realized the order was shifting on every restart and certain combinations failed or succeeded 100% of the time."
@jdonald Any chance that this issue could be fixed? Thanks!
Hi @pshkvsky,
I think we may have some workarounds for you, but at this point your issues do not seem to relate to the Double-decoration bug with auto_id
, or even autowiring itself.
So I'll take this offline and email you some info there.
Since a recent refactor on platform with the code
we are getting this error every minute or so on OS X machines :
They problem may lie in autowiring, although it's not clear.