19. Appendix 2: Common Vitaq errors¶
ImportError: DLL load failed: The specified module could not be found
AttributeError: type object ‘object’ has no attribute ‘__getattr__’
TypeError: SWIG director type mismatch in output value of type ‘bool’
OverflowError: in method ‘_GenField_uint64_is_value’, argument 2 of type ‘unsigned long long’
VitaqError: Trying to generate field “FPjSIKljKWCoVdEf” with no possible values remaining
Trying to add a custom range to a non custom generation field “GBmWSzXTO”, ignoring
Warning: allow_range(1, 10) called with no active constraints, this constraint will have no effect
19.1. Introduction¶
Below are details of some error messages that may be encountered whilst running Vitaq Test Activities. For each error message we identify the possible cause and potential fix.
Important
When reviewing Vitaq errors you need to look at the last line of the error message in the python output tab first and follow the error backwards from there. Of course, the error message will not be exactly the same as listed below, but this should help you to identify the error type and the format of the description that is important.
19.2. ImportError: DLL load failed: The specified module could not be found¶
Cause
This is caused by not having VERTIZAN_HOME/bin included in the PATH environment variable. This means that the Vitaq Python code is unable to find the underlying C++ libraries that are required for Vitaq Test Activities to run.
Fix
Add VERTIZAN_HOME/bin to the PATH environment variable.
Refer to installation guide for setting PYTHONPATH using rapid environment editor.
19.3. AttributeError: type object ‘object’ has no attribute ‘__getattr__’¶
Cause
While this appears to be an error with the Vitaq Python code, it is simply the point at which the error becomes apparent. It is caused in the test framework code when an instance variable (e.g. self.MyVariableA) is used before it has been defined.
Fix
Follow the traceback output from Python and find the last time that the test code was mentioned. From that find the line where the error occurs. On this line there is something that has not been defined yet. This can be an easy mistake to make if there are conditional statements and instance variables are defined within the conditional statements.
19.4. TypeError: SWIG director type mismatch in output value of type ‘bool’¶
Cause
This means that the SWIG wrapper was expecting a certain return type (in this case a bool), but it did not get that. A common cause of this is failing to return a boolean value from a do_seq method which is a requirement. Normally, one would implement checks to validate that the do_seq completed correctly and the checks return a boolean value.
Fix
If this is related to a do_seq, then make sure that there is a return statement that returns a Boolean value. This maybe the output of a check statement or simply:
19.5. OverflowError: in method ‘_GenField_uint64_is_value’, argument 2 of type ‘unsigned long long’¶
Cause
The argument specified is not of the type required
Fix
Check the type of the specified argument and correct.
19.6. VitaqError: Trying to generate field “FPjSIKljKWCoVdEf” with no possible values remaining¶
Cause
In the test code the option ‘do_not_repeat’ has been set meaning that values should only be used once and all of the values have now been used meaning that there are no more allowable values.
Fix
This situation can be detected ahead of time using the ‘has_allowable_values’ to see how many values are left. It can be reset using the reset_ranges method.
19.7. VitaqError: pack to string unsupported for this field type¶
Cause
Vitaq is unable to pack a boolean type.
Fix
Don’t try to pack boolean types
19.8. Trying to add a custom range to a non custom generation field “GBmWSzXTO”, ignoring¶
Cause
The distribution kind of the GenField has been set to flat, which means that distributions can not be applied to it.
Fix
Use the set_distribution_kind method to change the distribution kind to Custom (see the Enumerations section).
19.9. Warning: allow_range(1, 10) called with no active constraints, this constraint will have no effect¶
Cause
allow_range sets an additional allowable range after an allow_only_range method has been used. If allow_range is used first, then a range to allow is being specified, however the range has not been constrained in any way, so the entire range is already allowed.
Fix Constraint the range with allow_only_range before allowing additional ranges.