search

leapmotion / autowiring

A C++ Inversion of Control Framework
http://autowiring.io/
Apache License 2.0
148 stars 17 forks source link

Double-decoration error for auto_id<FlipDecision> #704

Closed jdonald closed 8 years ago

jdonald commented 9 years ago

Since a recent refactor on platform with the code

*packetOutput += [packetInputPtr, this] (const FlipDecision& flipDecision) {
  packetInputPtr->Decorate(flipDecision);
};

we are getting this error every minute or so on OS X machines :

[Critical] Unhandled exception: Cannot decorate this packet with type auto_id<FlipDecision>, the requested decoration is already satisfied
[Critical] An unhandled exception occurred in a device context: Cannot decorate this packet with type auto_id<FlipDecision>, the requested decoration is already satisfied

They problem may lie in autowiring, although it's not clear.

codemercenary commented 9 years ago

Could be an Autowiring defect, definitely requires further investigation.

codemercenary commented 9 years ago

@jdonald can you determine whether this issue is still present on 74798574b087f42a7a6fb57f37a2cf3533586821?

jdonald commented 9 years ago

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.

jdonald commented 9 years ago

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.

jdonald commented 9 years ago

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
codemercenary commented 9 years ago

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.

jdonald commented 8 years ago

Mimesis is also seeing this on Linux. Not sure why this happens so often on OS X and Linux but not Windows.

jdonald commented 8 years ago

FYI, I have tested locally and this is not fixed on the latest develop / 0.7.4 candidate.

codemercenary commented 8 years ago

Ok. This might be a race condition, will require further investigation.

codemercenary commented 8 years ago

I think #866 may have addressed this one.

jdonald commented 8 years ago

The packet decoration code that required this workaround was removed in leapmotion/platform#5096 (ref-recomb-part5), so this is no longer reproducible.

pshkvsky commented 7 years ago

Hi, Do you have this fix for Linux SDK?

jdonald commented 7 years ago

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/ ?

pshkvsky commented 7 years ago

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!

jdonald commented 7 years ago

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.