1. 13 Nov, 2014 1 commit
    • Tom Stellard's avatar
      ocl: Move static oclMat variables into FarnebackOpticalFlow class · 42b1bd56
      Tom Stellard authored
      Move some static functions into the FarnebackOpticalFlow class as well,
      so they can access these new class variables.
      
      oclMat objects cannot be declared statically, because their destructor
      depends on the statically defined __module variable from cl_context.cpp.
      Since statically defined variables in separate compilation units have
      an undefined destruction order there is always the possibility the
      __module will be destructed before an oclMat object, which results
      in a segfault.
      42b1bd56
  2. 12 Nov, 2014 1 commit
    • Tom Stellard's avatar
      ocl: Fix crash during destruction of gauss_w_lut object in hog.cpp · ec335b73
      Tom Stellard authored
      gauss_w_lut is a statically defined variable of type oclMat.  The oclMat
      destructor calls openCLFree() which via getInitializationMutex() accesses
      the __module variable which has been statically defined in cl_context.cpp
      
      Since the destruction order of statically defined variables in different
      compilation units is undefined, it is possible that __module will
      be destructed before gauss_w_lut, which would result in a segfault when
      getInitializationMutex() is called while destructing gauss_w_lut.
      
      In order to avoid this issue, we need to make gauss_w_lut a private
      member of the HOGDescriptors class so we know it will be destroyed
      before __module.
      ec335b73
  3. 15 Oct, 2014 1 commit
    • Tom Stellard's avatar
      ocl: Change static variable order in cl_context.cpp to avoid crashes during destruction · 8f3b876e
      Tom Stellard authored
      ContextImpl::currentContext contains a reference to one of the
      DeviceInfoImpl objects from:
      
      static std::vector<DeviceInfoImpl> global_devices;
      
      ContextImpl::currentContext is destroyed in the destructor
      for the statically defined object __module, and relies on its
      DeviceInfoImpl reference to query some hardware features while
      being destroyed.
      
      This means that we need to ensure that the global_devices vector is
      destroyed affter __module, otherwise ContextImpl::currentContext's
      DeviceInfoImpl reference will no longer be valid when __module is
      destroyed.
      
      Since these variables are all confined to a single compilation unit,
      they will be destruct from bottom to top, so we need to make sure
      that __module is the bottom definition so it can be destroyed first.
      8f3b876e
  4. 19 Sep, 2014 3 commits
  5. 26 Jun, 2014 1 commit
  6. 09 Apr, 2014 2 commits
  7. 28 Mar, 2014 2 commits
  8. 18 Mar, 2014 1 commit
  9. 17 Mar, 2014 1 commit
  10. 13 Mar, 2014 6 commits
  11. 06 Mar, 2014 1 commit
  12. 05 Mar, 2014 1 commit
  13. 04 Mar, 2014 1 commit
  14. 26 Feb, 2014 1 commit
  15. 12 Feb, 2014 1 commit
  16. 13 Jan, 2014 1 commit
  17. 27 Dec, 2013 2 commits
  18. 26 Dec, 2013 1 commit
  19. 20 Dec, 2013 1 commit
  20. 19 Dec, 2013 1 commit
  21. 18 Dec, 2013 1 commit
  22. 17 Dec, 2013 6 commits
  23. 12 Dec, 2013 1 commit
  24. 11 Dec, 2013 1 commit
  25. 05 Dec, 2013 1 commit