Common Errors/en

Aus expecco Wiki (Version 2.x)
(Weitergeleitet von Errors during Execution)
Zur Navigation springen Zur Suche springen

This document lists the most common error situations and provides advice on how to fix it. It is incomplete and does not cover all possible errors (but the list will grow over time).

Inhaltsverzeichnis

Project Load/Save Errors[Bearbeiten]

You are about to save the suite under another name...[Bearbeiten]

This warning and confirmation dialog is shown when you save a suite under another name; it tries to prevent a common error situation, in which two test suites or import libraries have the same functionID (unique identifier) and are therefore considered to be different versions of the same suite, although they should really be treated as two different suites.

Be reminded, that expecco associates a so called "function identifier" with every suite or library, and uses this to check for newer versions when (re-) importing. This allows for expecco to find matching elements and automatically find and replace newer versions during the reimport operation (independent, especially of an action's name, number of pins, types etc.).

However, if you actually intent to create a new suite or library, but want to use the current one to start with (i.e. as template), the above interpretation should be prevented and the suite should be given a new functionID first.

You are about to Overwrite a DIFFERENT Suite in...[Bearbeiten]

This warning and confirmation dialog is shown when you are about to save a suite into a file which already contains a suite with a different functionID (unique identifier). The suites are therefore considered to be different suites and NOT just different versions of the same suite.

Be reminded, that expecco associates a so called "function identifier" with every suite or library, and uses this to check for newer versions when (re-) importing. This allows for expecco to find matching elements and automatically find and replace newer versions during the reimport operation (independent, especially of an action's name, number of pins, types etc.).

Running out of File Descriptors[Bearbeiten]

If your suite opens a file stream, but does not close it, it may still be referenced in the activity log, and thus prevent the stream from being automatically closed (because the stream's finalization method is never called).

You may then - after opening thousands of such files - run out of file descriptors, which will lead to an error during execution and also when you want to save the suite (or perform any other file operation).

You can check for this situation by opening the external stream monitor via "Extras" - "Debugging" - "External Stream Monitor". If the list looks suspicious (i.e. super large), or contains files you think need to be closed, select them (use shift- or control click to select multiple) and choose the menu's "Close"function.

Fix your test case(s) to make sure, files are closed. You can also write a little elementary action to close all and every open file as:

   execute 
       FileStream allInstancesDo: #close

and invoke this at the end of your suite (or as post-action). Be aware, that this closes all open streams; so you better make sure that no current processing is ongoing (i.e. no execution is ongoing, and no other expecco tool is open). Btw.: the random number stream seen on Unix systems will reopen itself as soon as another random number is needed.

Editor Errors[Bearbeiten]

Datatypes (<type1> -> <type2>) are not compatible - press CTRL to force[Bearbeiten]

You tried to connect two pins, but the datatypes are not compatible. In some situations, expecco's interpretation of "being compatible" is too strict, and you may want to override this and force a connection.

This happens, if an output pin's datatype is more general than the input pin's type; for example, if you attempt to connect an output pin with a "Number"-type to an input pin typed as "Integer". Here, expecco assumes that the output value might be a Float, Rational or other non-integral number, which may cause trouble in the receiving action. However, you as a developer often know or can assert, that the actual output values will always be integral.

Usually, this happens when an action's output pins have been specified too general, and a good fix would be to change the type to either a more specific concrete type, or to a template type. You can also insert a cast step (either checking or non-checking) between the two pins.

A typical beginner's mistake is to define outputs as "Any" or "Object"; both will certainly lead to this kind of trouble later, when those actions are to be reused.

During execution, errors might be generated from various places. Common errors and how to deal with them is documented here.

Editor Warnings[Bearbeiten]

When editing a network, a background checker (called "Lint") looks for often encountered errors, and will occasionally write a message to the lower right info area of the expecco window.

Lint: Unreachable step(s) (eg. "xxx")[Bearbeiten]

Lint detected that the step named "xxx" seems to be not reached by any triggering data or control flow, or its trigger depends directly or indirectly on its own execution.

See below: " Steps not executed"

Execution Errors[Bearbeiten]

Pin Related Errors[Bearbeiten]

No value for input "x" of step "Y"[Bearbeiten]

A step's input pin has no input data. This happens if a step was started and a required input pin is missing. Notice, that this error is triggered only when a step-activity was triggered due to either the autostart flag (of the step) or by a trigger input value, or if the pin is non-triggering and another pin caused the trigger. And when the step's action accesses the input pin's data value.

In an elementary action, you can check for a pin to have received a value via the "pin.hasValue()" query.

Fix:

  • provide an input value either by:
    • set a default value for the pin in the step's action-block definition (the schema)
    • give the step's pin a freeze value (constant or variable)
    • connect the step's input pin to another step's output pin or one of the compound action's inputs
  • change the pin type to "parameter-pin" (especially if the step is in a loop). The pin will then no longer be considered in the trigger condition check, and the step will execute even if there is no value. However, a check for the presence of a value might be required inside the action to avoid an error there.
Output value x (x-class) is not compatible with datatype of pin "y" (y-class)[Bearbeiten]

An invalid datum (not matching the pin's type) was written to an output pin, typically inside an action with elementary code.

Fix:

  • check if the correct value is written to the pin
  • change the output pin's datatype to match the value's
  • change the output pin's datatype to Any (see note below)
  • change the output pin's datatype to # (template type; see below)
  • disable typechecks (usually not a good idea)
  • set the step pin's "Convert Value if Possible" special attribute

Point right.png Note: Output pins with Any-type are problematic: if that pin is ever to be connected to a pin with a more specific type, the editor may complain and refuse to connect the pins (unless you force a connection by pressing the CTRL-key). A better solution is to declare the output's type as a unique template type (say "#1", "#2",... , where "#N" is chosen to be unique among the other pin's types of the action block in question. The pin will then adopt the type to whatever it is connected later (i.e. it behaves like an Any until connected, and will then take the type of whatever it is connected to).

Telegram-data for non-triggering pin "x" of inactive step "Y"[Bearbeiten]

A telegram input pin (also called "mailbox pin") received a value after the step has already finished its execution. This is reported for non-triggering pins only - if it was triggering, a new activity would have been started. However, as the pin is non-triggering, the value is lost and there is noone to handle it.

Fix:

  • check if a mailbox pin is really required
  • either make sure that the mailbox input pin receives its value earlier (i.e. while the step is still being executed), or the target step is stopped later,
  • or set the "ignore exception" behavior of the target step (see note below)

Point right.png Notice: this error represents a special situation, in that actually neither the sending step, nor the mailbox-target step are individually responsible for the error. Also, because both have already finished, the error cannot be presented at either step's exceptionOutput pin, as this would lead to the strange situation, that both their trigger-output and their exception output pin's would be firing. Which would be illegal behavior. Therefore, the error is reported to the containing compound action, as its network is probably wrong.

In principle, this argument would also apply to the "ignore exceptions" flag. However, users found it convenient, to be able to ignore this error on the step level, instead of the compound level. Therefore a slight different semantic is implemented for this very error, in that it is ignored iff the target mailbox pin's step has the ignoreException flag set. Any errors internal in the target step are still reported via its exception output pin, if present.  

Errors Related to Variables (Environments)[Bearbeiten]

Trying to modify readonly variable: "x"[Bearbeiten]

The variable "x" has the read-only attribute.

Fix:

  • change the variable's "R/W" (read-write) attribute.


Execution Errors in Compound Actions[Bearbeiten]

Step not Executed in a Loop / Loop Executed only Once[Bearbeiten]

A common error when a diagram's steps are executed in a loop is that the input value of a step is consumed, and no other input value is present when the loop is executed the second time. Thus, there is no input value for the second iteration and the action will not execute again.

For this, change the pin's behavior to "Parameter".

Step is Triggered Again and Again (Machine Gun)[Bearbeiten]

Be careful to not make it both "Non-Consuming" AND "Triggering": the step may behave like a machine gun and start to constantly fire.

The "machine gun" behavior will appear if all triggering pins of the step are non-consuming. If there is any other consuming triggering pin (enable- or data input), this error will not happen.

The builtin lint-checker detects most of those and will give you a warning when you Accept the diagram.

Self-Retriggering does not Work[Bearbeiten]

Another common error situation may arise when a step is to be re-triggered by one of its own data output pins.
The idea is to fire the step again, once finished. A typical situation where this is useful is with the "[ Wait for Variable to Change ]" action, which is often used in GUI-action (and there usually waiting for some user interaction).

RetriggeredStepFromOutput.png

Be reminded, that there are two kinds of output pin behavior: buffered and unbuffered. Buffered means, that the value is written AFTER the step has finished successful, whereas unbuffered outputs are written immediately.

If the output is unbuffered (i.e. set to send its value immediately), then the new trigger will arrive while the step is still executing, and ignore the re-trigger.

Thus, this only works if the output pin is buffered, and thus writes its values after the step has finished. An alternative and better solution is to re-trigger the step from its "Enable-Output" pin (a non-data pin at the bottom). This will fire AFTER the step has finished and therefore will retriever the step.

In the screenshot, the first step will not correctly re-trigger itself (it has an unbuffered output), whereas the second works as expected (it uses the Enable-Output to re-trigger itself).

Fix:

  • Either make the output pin buffered, or (better) use the step's trigger-output pin for retrigger (which is by definition buffered and only send out a value AFTER the step has finished).

Execution Errors in DLL-Call Actions[Bearbeiten]

Cannot find or load dll/module: "<dllName>"[Bearbeiten]

Happens when a DLL-action block (not a bridged C action) could not load its underlying dll.

Go to the "Extras" → "Settings" → "Project Management" → "DLL Mappings" dialog and make sure that the folder in which your dll is located is listed in the DLL-Path list. If not, enter it, click on the "Add" button and save your settings.

Notice that the DLL-path setting is NOT stored inside the test suite, but instead a per-user/per machine setting which is stored in your ".expeccoSettings" file.

If the error is persistent, ensure that:

  • the dll is readable (i.e. check the access rights)
  • the dll is for the same OS+CPU architecture (especially check for 32bit vs. 64bit compatibility; also be reminded that windows dlls are not compatible with linux and vice versa).
  • any other dlls required by the dll (i.e. second level dependencies) are also found along you path (windows) or LD_LIBRARY_PATH (unix/linux). Check this using an appropriate command line tool (ldd or similar tools)
Missing function: "<functionName>" in shared library: "<dllName>"[Bearbeiten]

A function (as specified in a DLL call action) was not found in the DLL (although a DLL by that name was found and has been loaded). Check for a mistyped function name in your DLL-call action, correct export definitions (windows ".def" files), up-to-date library (recompile/relink) and wrong path settings (loading the wrong dll).

Execution Errors in Bridged Actions[Bearbeiten]

Timeouts[Bearbeiten]

When communicating with a bridge, expecco will report an error, if the bridge does not respond in a reasonable time. Expecco uses different time limits (timeouts) for:

  • connecting (starting the interpreter). This includes the time it takes for the interpreter to load any initial packages/modules. This timeout can happen only once, when the bridge is initially started.
  • defining an action. This is the time it takes the interpreter to define a new execute function. This timeout may happen once per type of action, when that action type is first executed.
  • execute an action. This is the time it takes to send pin values to the action. This timeout may happen if a huge amount of data is passed (eg. a huge vector of floats).

All timeouts can be adjusted both as default value for new bridges or for an already instantiated individual bridge.
See FAQ on Bridges for details.

Execution Errors in Bridged C Actions[Bearbeiten]

Failed to load Shared Library[Bearbeiten]

This issue refers to bridged C actions - not DLL actions.

Ensure that a correct toolchain (as called by the configured compile-script) is invoked. A common error on windows is a mismatch between a 64/32 bit cBridge and a 32/64 bit toolchain. The cBridge will report an error 193 when trying to load a generated or dependent dll.

On Windows, virus scanners sometimes prevent a file from being loaded. The cBridge will report an error 126 when trying to load a generated or dependent dll which is currently locked by the scanner. Starting with expecco 23.2.77, the cBridge will retry the dll-load a few times as a workaround.

Ensure that the shared libraries are found. Under Unix/Linux, you may want to set the LD_LIBRARY_PATH shell variable; under Windows, dlls are searched along the PATH and in the cBridge.exe's own folder. A best practice is to set it before expecco is started, usually in your loginrc file. As alternative, set it in "Extras"- "Settings" - "Execution" - "External Script Interpreters". The standard library also contains an action to set the PATH inside the bridge.

You can also take one of the existing compile scripts in the bridge folder, copy it to a new name, and add your shared library to the link command at the end. Then specify this compile script in your expecco settings. Consult the compiler-toolchain's manual pages on how shared libraries are searched and resolved; typically there is a commandline argument for the linker (such as -L or -linkPath) which tells the executable where libraries are to be found.

If all fails, copy or symlink your shared library to the cBridge folder ("installDir/packages/exept/expecco/bridgeFramework/cBridge").

Execution Errors in Bridged Node Actions:[Bearbeiten]

Cannot find module 'x'[Bearbeiten]

Happens when a Node.js action contains a requirement for a module which has not been installed. Fix:

  • install the module with "npm install x" or via the "Plugins" → "Bridges" → "Node Bridge" menu.
  • check your node-module-path ("Module Path" field in "Extras" → "Settings" → "Execution" → "External Script Interpreters") or the shell environment variable named "NODE_PATH".
  • check if the modules was actually installed in the folder given by the module-path (noticing that there are both a global "node_modules" and a per-user "node_modules" folder)

Point right.png Notice: a change of the module-path, does not affect already running node.js bridge connections. You have to close all current (node.js) connections and retry the action.  

Execution Errors in Bridged Python Actions:[Bearbeiten]

Package not Found (although it was previously installed)[Bearbeiten]

Individual Python versions use different folders where they install and later search their packages. If a package is installed in a (say) Python3.7 installation, it will not be found by a previously installed Python2.7 or another Python3.9 version.

The situation becomes even more confusing when "pip install" is used: you have to double check, where pip is going to install the package.

As a best practice, use the explicit "pythonX.Y -m pip install" command, and define "pythonX.Y" as python path in the expecco settings (or define the module path).

TypeError: Object of type X is not JSON serializable[Bearbeiten]

You tried to send a Python object to an output pin or to pass it to one of the log/print functions, but the Python object is not JSON serializable (be reminded, that values are JSON encoded when transmitted between expecco and the Python program).

Possible fixes:

  • define the pin's type as String, and write "str(obj)" to it. Thus effectively passing a printed string representation. However, you might have to define an extra decoding action in expecco for the object to be decoded (typically into an instance of a user defined compound type).
  • send a reference to the object to the output pin (i.e. write "makeRef(obj)" to it). This will transfer a transparent handle (think of it as a pointer) to the object to expecco. You may then later send the object reference back to Python, but it may be harder to extract fields inside expecco (best is to define getter-actions to the fields in python and invoke those later).
  • extract the required fields and send them to individual output pins (instead of writing the object as a whole)

Notice that some expecco datatypes are able to decode the object from the printed representation, even if it is non-serializable. You may try to set the pin's "Convert Value if Possible" special attribute in the action's schema and write the string representation (as above, with "str(obj)"). Expecco will then try harder to reconstruct an object from the string representation. This works eg. with unit quantities as generated by the Python astropy package.

Compound Actions: Strange Behavior in Loops[Bearbeiten]

Step in a Loop is Executed only Once[Bearbeiten]

This is a common problem with input pins which consume their value; be reminded that pin-connections are actually little event queues, and data values are transported as packets along them. Whenever such a packet arrives at a pin, it is enqueued and consumed, when the step is executed. At the same time, the arrival of such a packet is a trigger condition for the execution, unless the pin was declared as being non-triggering.

If a step is arranged in a loop (either explicitly, using enableIn-enableOut control pin loops, or via a repeat-count input or implicitly, by being fed with data from a multiple data generating step), pins may happen to have no input data available when triggered the second time.

This situation is especially common, when one pin is fed via a generator, and another pin's value comes from either a compound input pin, or another step which is executed only once.

Fix:

  • change all input pins of the step which do not receive multiple values, and which should reuse the previous value throughout the loop to be "non-consuming" or "parameter" pins. This is done via the step's popup menu. Be aware that parameter pins are neither consuming, nor triggering. Thus, with a parameter pin, the step could in theory be triggered before a value arrives. You can also make it non-consuming, but still triggering, so the step will await for the first value to arrive at the pin (and, because it is non-consuming, it will remember this value for the next iteration of the loop). However, do not use this pin setup (trigger and non-consuming) for steps which are not in a loop; i.e. which are not triggered via an enable-input or other consuming triggering input. Because these might then behave like "machine guns" and re-trigger themself automatically.
Step in Loop is not Executed at All[Bearbeiten]
StepNotExecuted1.png
StepNotExecuted2.png

If a step has an enableIn control pin, it will need a trigger value at this pin.
If you have constructed a loop which is connected via enableOut-enableIn control pins, the loop will not start, as no initial trigger ever appears.

Fix:

  • To provide this initial trigger, add any dummy step, which generates an output and feed that as additional input to the loop-top's enableIn pin.
Any output and especially a trigger-output will do.
The standard library provides such a block named "Start", which is actually a No-Operation block, and its sole purpose is to provide such an initial trigger condition.
Make sure that the Start step is itself triggered, usually by setting its autostart execution flag.

 

Wrong Input Values in a Chain of Looped-Over Steps[Bearbeiten]

Imagine a number of steps in a chain, which are triggered multiple times by eg. a generator. Also imagine, that values flow through that chain, in pairs or tuples, such that steps generate multiple values at their outputs which are connected to multiple inputs of steps further down the chain.

Also imagine, that some value from the start of the chain needs to be reused as input further towards the end of the chain and that some intermediate steps might be skipped sometimes (for example, due to a handled exception).

The problem with such a setup is that values from the next iteration may mix up with values from a previous loop iteration at a step near the end of the chain.

Fix:

  • put all steps which are in the chain into a separate compound action.
    The editor's right-button-menu has a special function for that ("Extract and Replace by New Compound Action" under the the "Refactor" menu item).
Action does not Finish in a Producer-Consumer Setup[Bearbeiten]

A common pattern is that one step generates multiple data values (or tuples), and another one collects those, usually after being processed by some other action(s). For example, a test-data generator might produce data-tuples which are fed to a test case, and the results are collected to be further processed and generated as a summary output of the compound action. The problem here is that the collecting block needs to remain active until the last input value arrives, but it usually does not know, when to stop. There are multiple possible solutions to this:

  • provide an END-token via a second pin and use that as a cancel or end-trigger. Many of the enumerating action blocks in the standard library provide such an END token already.
  • use one of the "All Data Processed" or "No other Action active" blocks from the standard library. These can trigger a signal, if all data has been processed within a diagram and their output be used to signal the end condition.

Other Errors[Bearbeiten]

Python: ENOENT spawn git (when installing npm packages)[Bearbeiten]

"npm" might need git for its operation. You should install git from [ https://git-scm.com/download/win ] first.
Then try again.



Copyright © 2014-2024 eXept Software AG