leapmotion / autowiring Goto Github PK

It seems that the issue is a result of some filters using type T, while others using std::shared_ptr. The problem was introduced by #712.

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.

AutoNet seems to be having some pretty serious problems as of v1.0.0. In particular, not all of the context information is correctly relayed to the front end, and it does not update continuously.

One possible problem is the recent update to websocketpp, another possibility is a change to how Autowiring reports context events to clients. Investigate, and fix the problem.

If a user attempts to call parallel::begin and the current context is not running, throw an exception.

Right now, I must call subscribe to get custom events, which means a lot may be sent which is not required. It would be nice if custom events came through without the others.

I'm tired of looking at the warning in PriorityBoost.cpp, it's about time we got around to implementing this.

It's likely all we need to do is to call the nice function or near equivalent, we just need to make sure we do so in a way that will also work properly on Mac.

We build with Autowiring with VS2017 (version 15.5.7) on Windows. But it failed with the error C2039, C2878, C2065, C2146, C3083. This issue can be reproduced from master revision fc48e3b. Could you please help take a look at this? Thanks!

Repro steps:

1. Open VS2017 x86 Native tools command tool
2. git clone https://github.com/leapmotion/autowiring d:\Autowiring\src
3. cd D:\Autowiring
4. mkdir build_x86 && pushd build_x86
5. cmake -G "Visual Studio 15 2017" -DCMAKE_SYSTEM_VERSION=10.0.16299.0 ..\src\
6. msbuild /m /p:Configuration=Release;Platform=Win32 Autowiring.sln /t:Rebuild

Error info:
The whole log file please see attachment.
log_x86_build.log
Build FAILED.
"D:\Autowiring\build_x86\Autowiring.sln" (Rebuild target) (1) ->
"D:\Autowiring\build_x86\ALL_BUILD.vcxproj.metaproj" (Rebuild target) (2) ->
"D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj.metaproj" (Rebuild target) (10) ->
"D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj" (Rebuild target) (21) ->
(ClCompile target) ->
D:\Autowiring\src\src.\autowiring/C++11/filesystem.h(9): error C2039: 'filesystem': is not a member of 'std' [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src.\autowiring/C++11/filesystem.h(9): error C2878: 'filesystem': a namespace or class of this name does not exist [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(16): error C3083: 'filesystem': the symbol to the left of a '::' must be a type [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(16): error C2039: 'path': is not a member of 'std' [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(16): error C2065: 'path': undeclared identifier [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(16): error C2146: syntax error: missing ';' before identifier 'p' [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(16): error C2065: 'p': undeclared identifier [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(17): error C3083: 'filesystem': the symbol to the left of a '::' must be a type [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(17): error C2039: 'path': is not a member of 'std' [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(17): error C2065: 'path': undeclared identifier [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(17): error C2065: 'p': undeclared identifier [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(17): error C2228: left of '.extension' must have class/struct/union [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(17): error C2512: 'testing::AssertionResult': no appropriate default constructor available [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(18): error C3083: 'filesystem': the symbol to the left of a '::' must be a type [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(18): error C2039: 'path': is not a member of 'std' [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(18): error C2065: 'path': undeclared identifier [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(18): error C2065: 'p': undeclared identifier [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(18): error C2228: left of '.filename' must have class/struct/union [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src\autowiring\test\FileSystemHeaderTest.cpp(18): error C2512: 'testing::AssertionResult': no appropriate default constructor available [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]

If you try and set a breakpoint in a function with a couple of autosignals on the callstack, it hangs visual studio. Admitedly, this is a problem with Visual Studio, but in practice it means that debugging code that uses autosignals on windows is extremely cumbersome.

AutowiringEnclosure now checks to ensure that GlobalCoreContext is not leaked at the end of a test. This is a good thing to be checking, but some legacy tests are not written cleanly and so are failing.

Add a flag to optionally skip this check and preserve the old behavior until clients can fix these leaks.

DispatchQueue is used for a number of concurrent consumer operations, and it has quite awful scalability. It was originally designed for the single-consumer use case, which means that this circumstance is not necessarily a design flaw, but it's about time that it be updated.

Switch to a lock-free data structure for introducing new entries into the queue (maybe a circular buffer?), and consider platform-specific optimizations to receive notifications of entries added to the queue. Also consider allowing DispatchQueue::WaitForEvent to consume all events in the queue, and make better use of condition_variable::notify_one in order to reduce the load on the scheduler.

In cases where we manage our contexts using the ContextMap, it would be nice if we could terminate and release the weak pointers in the map. For example:

void MyClass::Reset() {
    for (auto ctxt : m_ctxtMap) {
        ctxt->SignalShutdown();
    }
    m_ctxtMap.Clear();
}

This problem was first discovered 27 days ago in http://sf-github.leap.corp/leapmotion/platform/issues/2602

We have spent time debugging it and still don't understand the mechanism. Perhaps this is due to some interaction between auto_prev and auto_out accumulated arguments e.g. const FigureSubFrame* frames[].

We can verify that Figure3D::AutoFilter is called in normal operation, but then the entire AutoFilter function stops getting entered as soon as the 'p' key is pressed in Figure. This happens if and only if an AutoFilter using auto_prev is injected. For example, the problem can be reproduced via HandOpticalFlow :

LeapSvc.exe --run --tracking_version=v2_init

but when the AutoRequired() is removed, the pause/unpause problem goes away.

This applies to injecting HandOpticalFlow, HandOpticalFlowDebug, or HandDepthEstimate all of which use auto_prev. With V3 tracking, many of these classes have become necessary, making this issue more of a concern.

All CPP and H files should have the Leap Motion copyright string at the top; adjust the linter so that it will validate this in addition to validating our tab/space stuff.

https://github.com/fmtlib/fmt provides a mature, well tested, and extremely fast implementation that would avoid potential format conversion problems.

Pointing autowiring_DIR at the root dir (e.g. /path/to/autowiring-0.5.4) doesn't satisfy find_package. Pointing autowiring_DIR at the cmake subdir does work, but I wouldn't consider this to be "the autowiring dir", so it's somewhat misleading.

Recommend putting the relevant cmake files (autowiring-config.cmake and autowiring-configVersion.cmake) in the autowiring root dir.

There appears to be a race condition in Autowiring where adding an AutoFilter
lambda to a packet while it is processing may result in it being called twice.

This problem happens in Platform (See PR #4044).

The failure is due to our CoreThreadLinux adjustments in #786. Here's the error:

src/autowiring/CoreThreadLinux.cpp: In member function 'void BasicThread::SetThreadPriority(ThreadPriority)':
src/autowiring/CoreThreadLinux.cpp:37:14: error: 'SCHED_IDLE' was not declared in this scope
     policy = SCHED_IDLE;

We need to fix this, or turn off this feature on Android.

ObjectPool has terrible performance because we used std::shared_ptr to track objects that are in the cache, when really we should be using std::unique_ptr. This design choice was made in order to support libstdc, but because we no longer support it, we should probably fix ObjectPool's current performance issue, especially if we are recommending that people use it in preference of operator new.

This one is a complex one. We need the ability to add information about the decorations that will be attached by a particular AutoFilter at runtime, rather than relying exclusively on information gained from the signature of the AutoFilter itself.

This will allow us to have an AutoFilter that accepts an AutoPacket&, but still have some information about what types of decorations that filter is responsible for attaching at runtime. Furthermore, we can tighten behavior down by requiring that filters which accept an AutoPacket& as an input explicitly declare the decorations they intend to attach--or else they will not be permitted to attach any.

Suggested syntax:

void MyFilter::AutoInit(void) {
  AutoRequired<AutoPacketFactory> factory;
  factory->Augment<MyFilter, DecorationType0>();
}

This syntax relies on Autowiring's AutoInit behavior, which is invoked on an object immediately after it is injected into a context and registered but before it is made a candidate for autowiring. This registration step can't be done from the constructor, because the filter won't been added to the AutoPacketFactory until the object is completely constructed.

This includes

• A tutorial that provides a general overview of the library and best practices
• A comprehensive api doc
• Expand the wiki

AutoInjectable is deprecated and has weird behaviors. Remove it.

Example use case is with sliders, which use NotifyWhenAutowired on Figure. When I start LeapSvc with a device plugged in, a couple frames will tend to get processed before Figure comes online.

However, once Figure is autowired, these are often triggered in a different order than the m_Params.NotifyWhenAutowired line was called, which knocks sliders from their intended ordering.

This doesn't happen when I plug in a device after a few seconds, since at that point the calls to add sliders are processed immediately.

My version of Clang crashes while compiling any Autowiring source file. This happens in the preprocessor step while trying to parse cpp11.h. The error message is:

0 clang 0x0000000100c57bb2 main + 12932498
Stack dump:
0. Program arguments: /usr/bin/clang -cc1 -triple x86_64-apple-macosx10.7.0 -emit-obj -disable-free -disable-llvm-verifier -main-file-name NewAutoFilter.cpp -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 136 -coverage-file /Volumes/Disk Image/os-controls-build/contrib/autowiring/src/autowiring/CMakeFiles/Autowiring.dir/NewAutoFilter.cpp.o -resource-dir /usr/bin/../lib/clang/4.2 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -D NDEBUG -I /Users/vdods/lm/os-controls/contrib/autowiring/. -I /Users/vdods/lm/os-controls/contrib/autowiring/contrib -I /Users/vdods/lm/os-controls/contrib/autowiring/contrib/websocketpp -I /Users/vdods/lm/os-controls/contrib/autowiring/contrib/gtest-1.7.0/fused-src -I /Users/vdods/lm/os-controls/contrib/autowiring/autowiring -I /opt/local/Libraries/boost_1_55_0-libc++/include -fmodule-cache-path /var/folders/d6/4b7tq65j6r9dcmpj7y2f0w980000gn/T/clang-module-cache -stdlib=libc++ -O3 -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /Users/vdods/lm/os-controls-build/contrib/autowiring/src/autowiring -ferror-limit 19 -fmessage-length 148 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.7.0 -fobjc-dispatch-method=mixed -fobjc-default-synthesize-properties -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o CMakeFiles/Autowiring.dir/NewAutoFilter.cpp.o -x c++ /Users/vdods/lm/os-controls/contrib/autowiring/src/autowiring/NewAutoFilter.cpp

1. /Users/vdods/lm/os-controls/contrib/autowiring/./contrib/C++11/cpp11.h:55:4: current parser token 'if'
2. /usr/bin/../lib/c++/v1/__config:275:1: parsing namespace 'std'
   clang: error: unable to execute command: Segmentation fault: 11
   clang: error: clang frontend command failed due to signal (use -v to see invocation)
   Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
   Target: x86_64-apple-darwin11.4.2
   Thread model: posix

I went in and hacked cpp11.h to see what was causing the crash and it was the use of __has_include at line 52. I tried replacing <initializer_list> with in that __has_include directive, and it still crashed. Taking the call to the __has_include directive fixed the crash, but obviously leaves a hole in the functionality. Thus a hack-workaround is to change the line

#define HAS_INITIALIZER_LIST __has_include(<initializer_list>) && __has_feature(cxx_generalized_initializers)

to

#define HAS_INITIALIZER_LIST __has_feature(cxx_generalized_initializers)

E.g. if c is a context and s is an instance of a class with an AutoFilter method, then the call
c->Snoop(s)
looks like it should cause c to snoop s, but it really means s will snoop c. This is misleading.

AutoFilterTest.DeferredRecieptInSubContext fails after ~500 iterations.

Recreate

run AutowiringTest --gtest_filter="AutoFilterTest.DeferredRecieptInSubContext" --gtest_break_on_failure --gtest_repeat=10000

I'm tired of having to update autowiring.io by hand. It should be possible to use a tag-based deploy trigger in Travis to have the build server generate and update our documentation as soon as a tag is laid in.

• Read the travis deployment guide to determine the best way to deploy documentation
• Configure Travis to deploy any time a new tag is pushed
• Filter tags so that deployment only happens if a tag is of the form v1.2.3, or exclude any tag that is not a release

As we are using AutoNetServer as the RPC messaging, we should look into adding TLS support so that AutoNetServer can communicate with web applications with a more secure protocol

In CmakeLists.txt, using linux with clang 3.4.2, I have to change:

set(CMAKE_CXX_FLAGS "-std=c++11 -stdlib=libc++")

to

set(CMAKE_CXX_FLAGS "-std=c++11")

in order for it to compile. If I use the "-stdlib" flag, the compile can't find standard library headers (e.g., ).

For example:

[  1%] Building CXX object contrib/json11/CMakeFiles/json11.dir/json11.cpp.o
In file included from /home/ndoss/autowiring/autowiring/contrib/json11/json11.cpp:22:
/home/ndoss/autowiring/autowiring/contrib/json11/json11.hpp:53:10: fatal error: 
      'string' file not found
#include <string>
         ^
1 error generated.

If class A autowires class B, and class B autowires class A, the resulting cyclical dependency will keep them both alive even after context teardown.
This is bad behavior, and if at all possible, we should add some mechanism for automatically detecting this kind of thing to either autowiring itself (which should throw an exception, likely runtime if found) or to AutoNet

This causes a crash when mask_shared is called when the type needs to be aligned in a specific way in memory.

ObjectPool has a constructor overload which allows callers to override default memory allocation. This makes two separate allocations necessary and can be very inefficient. Remove the allocating constructor completely, and then use alignof to satisfy alignment requirements.

We need a way to obtain the current packet from anywhere under an AutoFilter. Create a new static method called AutoPacket::CurrentPacket which will return the current packet when the AutoFilter is being called, and will return nullptr when an AutoFilter is not on the call stack. Use dumb pointers for speed, here, not smart pointers.

Comparisons against std::type_info are causing substantial performance degradation, we need to address this by removing all uses of std::type_info wherever it's necessary to perform runtime dynamic type handling. Afterwards, benchmark the speed of Autowired and AutoFilter to determine how much of a performance improvement we get.

Let the following code work:

for (int i : {0,4,2,5,1,3}) {
  int sleepTime = dist(mt);
  p += [i, sleepTime]() {};
}

std::vector<int> result;
for (auto it = p.begin<void(); it != p.end<void>(); ++it);

A specialization for parallel::begin<void> is needed to get this code functional.

When playing with DispatchQueueTest.Barrier line 77, the unit test would fail with std::chrono::nanoseconds was 1e4, but pass with 1e5

All of our copyright headers are through 2014

I get a number of build errors when compiling with without USE_LIBCXX (using libstdc++). These include:

• Use of undeclared identifer 'nullptr'
• Redefinition of '_1' with a different type: 'boost::lambda::placeholder1_type' (aka 'const lambda_functor<placeholder >') vs '__ph<1>'

I think the nullptr problem is the root cause.

Related to #671, Cyclical dependencies are bad, but if all Autowired fields were automatically reset on context teardown, they would be much less of a problem.

I get this error frequently, but the message is very unhelpful. Surely with RTTI we can at least print out a string representation of the offending type?

The websocketpp server isn't shutdown cleanly when AutoNetServer is stopped with open connections. This causes this error when you try and restart the server

asio listen error: system:48 (Address already in use)

A fix is addressed here

Description:

A service crash occurs after sleep/resume. This did not occur on Develop prior to autowiring update. Stack trace and branch commit hash attached below.

Frequency:

10/10

Found In:

UPD-Autowiring branch: a0c90e87cc9e174272aa3f1150d90810f8c9e97a

Notes:

Stack Trace:

msvcr120.dll!abort() Line 88 C
msvcr120.dll!_purecall() Line 59 C
LeapSvc.exe!autowiring::signal::operator()(enum VigilanceReason &&) C++
LeapSvc.exe!operator<<(class std::basic_ostream<char,struct std::char_traits > &,enum LEDMode) C++
LeapSvc.exe!DispatchQueue::DispatchAllEvents(void) C++
LeapSvc.exe!CoreJob::DispatchAllAndClearCurrent(void) C++
LeapSvc.exe!std::_Func_impl<struct std::_Callable_obj<class std::_Bind<0,void,class <lambda_21250f153e69945bed5dd5697e2e3945> >,0>,class std::allocator<class std::_Func_class >,void>::_Do_call(void) C++
LeapSvc.exe!std::_Packaged_state::_Call_immediate(void) C++
LeapSvc.exe!std::_Func_impl<struct std::_Callable_obj<class <lambda_2cb696077b3339a1ae8328ae0c6c0dec>,0>,class std::allocator<class std::_Func_class >,void>::_Do_call(void) C++
LeapSvc.exe!std::_Func_impl<struct std::_Callable_obj<class <lambda_76f314ecb5e1c9167539137e0dc2f350>,0>,class std::allocator<class std::_Func_class >,unsigned char>::_Do_call(void) C++
LeapSvc.exe!Concurrency::task::_InitialTaskHandle<void,class <lambda_781036f848fffa6eb15265e2650f848e>,struct Concurrency::details::_TypeSelectorNoAsync>::_Init(struct Concurrency::details::_TypeSelectorNoAsync) C++
LeapSvc.exe!Concurrency::details::_PPLTaskHandle<unsigned char,struct Concurrency::task::_InitialTaskHandle<void,class <lambda_781036f848fffa6eb15265e2650f848e>,struct Concurrency::details::_TypeSelectorNoAsync>,struct Concurrency::details::_TaskProcHandle>::invoke(void) C++
msvcr120.dll!Concurrency::details::_UnrealizedChore::_UnstructuredChoreWrapper(Concurrency::details::_UnrealizedChore * pChore) Line 293 C++
msvcr120.dll!Concurrency::details::InternalContextBase::Dispatch(Concurrency::DispatchState * pDispatchState) Line 1716 C++
msvcr120.dll!Concurrency::details::FreeThreadProxy::Dispatch() Line 203 C++
msvcr120.dll!Concurrency::details::ThreadProxy::ThreadProxyMain(void * lpParameter) Line 174 C++
kernel32.dll!BaseThreadInitThunk�() Unknown
ntdll.dll!RtlUserThreadStart�() Unknown

ENG Requirements:

It is a known bug that make_shared does not honor data alignment requirements.

converting this type of code:
auto ptr = std::make_shared(std::forward<T&&>(t));

To:
auto ptr = std::shared_ptr(new TActual(std::forward<T&&>(t)));

Will fix the issue(s)

There's a defect introduced in #866 which is causing a multi-decorate problem to appear on initialization in certain user build cases. This defect is serious enough to merit a patch release this week to correct the problem.

The issue is only reproduceable in platform. This is a copy of the error log:

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

A call to CoreContext::SetUnlinkOnTeardown is currently required to enable teardown unlinking in CoreContext. To reduce the likelihood of context member leaks due to cyclic references, make teardown unlinking the default behavior.

This will require that we verify downstream consumers are not adversely impacted by this modification, as any unchecked references to an Autowired field during teardown may potentially result in a null pointer dereference.

The Linux package contains Autowiring-1.0.3-Linux, not autowiring-1.0.3-Linux as expected.

Connected to leapmotion/PipelineAutomation#864

The time has come...

The changes to AutoNetServerTest.h in commit 441ddc1 breaks the compile for the autonet tests for me (linux, clang 3.4.2 & gcc 4.9.1). If I revert the file, the autonet tests compile & run for me.

Fix this so we can deploy

Here's the output from gtest:

C:\Development\autowiring\src\autowiring\test\AutoSignalTest.cpp(630): error: Value of: magic
  Actual: 15987178197214944733
Expected: 0xDEADBEEFC0FECAFE
Which is: 16045690984335330046

Build Autowiring with /std:c++17 with Visual studio 2017(version 15.5.7) on windows failed with following failures, could you help have a look?

D:\Autowiring\src\src.\autowiring/C++11/filesystem.h(20): error C2874: using-declaration causes a multiple declaration of 'std::experimental::filesystem::v1::path' [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]
D:\Autowiring\src\src.\autowiring/C++11/filesystem.h(26): error C2874: using-declaration causes a multiple declaration of 'std::experimental::filesystem::v1::filesystem_error' [D:\Autowiring\build_x86\src\autowiring\test\AutowiringTest.vcxproj]