These functions are found in the "Extras" → "Debugging" menu.
Show all External Connections
Opens an inspector on all external connections which possibly hold a handle to either a socket, pipe or serialPort. The inspectors presents a list of those connections and a menu function to close them selectively (via the menu or by evaluating "
self close" in the inspector). Notice, that all open streams are shown, including stderr and stdout. Do not close those.
Shut Down Bridge Connections
Tears down leftover Java, DotNet, Python, NodeJS and C Bridge connections.
Close all Socket Connections
Tears down all open socket connections (interprocess communication).
Close all Serial Connections
Tears down open serial connections
Show Memory Usage by Object Type
Detailed information about memory usage
Under normal conditions, you don't have to care about expecco's memory: its underlying support system performs automatic memory management (garbage collection). This includes automatic finalization of objects which refer to operating system resources such as file handles, database-connections etc.
However, these finalizations may happen quite delayed, due to the fact that the garbage collector is usually only invoked when running out of memory or when more memory is requested. This means, that if a file- or database handle has not been closed, but is also no longer used by a testSuite, that handle will be closed (and thereby freed) whenever the next garbage collect operation occurs. Which, if no memory is needed for some time, may happen quite delayed.
Another situation in which handles are still referenced (and therefore not closed automatically) is when such handles are still present in an activity-log/trace. Because all data which was interchanged between steps is recorded there, handles may end up being recorded and therefore considered to be still "in-use" by the automatic memory management.
This tool-function forces a garbage collect operation to be triggered immediately, and thereby freeing any unreferenced operating system resources. When those resources get collected, a finalize function is called automatically, which closes the associated operating system handle. Use this, if you have the feeling that the system is using many file, window, socket or other handles.
Notice: the automatic memory management can of course only free memory which is completely unreachable. This means that objects which are still referenced by other referenced objects will not be reclaimed. In expecco, one such "top level" referrer is usually the result log/execution trace of the previous execution(s).
This is the storage you see when inspecting pin values after an execution. For example, if a socket or file handle is stored in this execution trace, AND this handle was not properly closed (either because the suite simply forgot to close it, or because the test was aborted and the suite provided no close in its post-action), then the handle might be stored in the log, and is therefore never closed automatically.
This behavior is not a bug: it is often very useful to have external connections still open when looking at the activity-log, because in many contexts you can inspect and interact with the connection if it is still open (remember that objects in remote machines are only references via handles, which are invalid, if the underlying bridge connection gets closed). This is especially useful for UI connections and in the inspector tool.
In this case, you should either "Remove all Results in System" (in the "Test-Results"-menu), and then perform a memory cleanup, or use one of the other maintenance functions from the debugging menu to close handles (i.e. "Close all Sockets", "Close all Bridge Connections", "Close all Serial Connections" etc.).
Back to Online Documentation.