STOptionInvalidParameterException and compiler warnings


Have just updated my in-progress app to the SDK (0.7), running on iOS 11.3 and Xcode 9.3 beta (yeah, bleeding edge FTW!).

Seems to be working okay so far, save for a few intermittent errors and warnings.

The primary one is a ‘crasher’ showing as the following in the logs:

[StructureSDK] Throwing exception STOptionInvalidParameterException: Parameter `options’ value is invalid: It cannot be nil.

Can’t find any reference to this on Google, the forums, or the SDK docs, and have no idea where to look for what is causing it.

Any one else seeing this?

Second are a number of warnings triggered by StructreSLAM.h:

/// Most recent estimated camera pose, taking Structure Sensor as a reference.
@property (nonatomic, readonly) GLKMatrix4 cameraPose; __deprecated_msg(“use lastOutput instead.”);

/// Whether the pose initializer could find a good pose.
@property (nonatomic, readonly) BOOL hasValidPose; __deprecated_msg(“use lastOutput instead.”);

/// Whether the last cube placement was made with a supporting plane. Useful for STMapper.
@property (nonatomic, readonly) BOOL hasSupportPlane; __deprecated_msg(“use lastOutput instead.”);

All three of these lines give a Swift Compiler warning of ‘Declaration does not declare anything’ Looks like something to do with my bridging header in my Unit Tests target, or iOS 11.3 in cdefs.h

#if __has_extension(attribute_deprecated_with_message) ||
(defined(GNUC) && ((GNUC >= 5) || ((GNUC == 4) && (GNUC_MINOR >= 5))))
#define __deprecated_msg(_msg) attribute((deprecated(_msg))) // <<<<<<<<<<< THIS LINE
#define __deprecated_msg(_msg) attribute((deprecated))

Again, any ideas?


Did you manage to solve that crash (Throwing exception STOptionInvalidParameterException: Parameter `options’ value is invalid: It cannot be nil.) ?

I’m getting it while running the app from Xcode in remote debugging (wifi) intermittently.



Hi. No, didn’t manage to solve it.

Figured out I only got it if starting the app with the sensor plugged in, so easiest way to get past it was unplug the sensor, start the app, then plug the sensor back in. Figure it is the sensor responding with incorrect response.




I see, thanks.

Can anyone from Occipital confirm that this is a known bug?