How to get around TPTP's IWAT0435E in Windows

Question

I have just installed TPTP's latest version (4.6.1) and am using Eclipse build 20090621-0832 on Windows 7 (User Control enabled).
I'm trying to profile an application but am getting the following error under the Monitor tab:

IWAT0435E An error occurred when connecting to the host.

Anyone know how to resolve this?

Answer 1

For Windows, this may be related to a missing reference to the Integrated Agent Controller (IAC)

The Integrated Agent Controller (IAC) is a new feature in TPTP workbench which allows users to profile a Java application locally and to run a TPTP Test locally without needing the standalone Agent Controller on the local machine.
Profiling on a remote machine or running a TPTP test on a remote machine would still need the Agent Controller on that remote machine.
The biggest benefit of the Integrated Agent Controller is that it simplifies the usage of TPTP functionality in the local scenario by removing the dependency on the local standalone Agent Controller. There is no need to install and configure the local standalone Agent Controller when using the Profiling and Logging perspective and Test perspective locally.

However, that local agent might not be referenced correctly in one of the TPTP config files, either because:

• it is already referenced in the workspace (incorrectly)
  See workspace\.metadata\.plugins\org.eclipse.tptp.platform.iac.administrator\config\ serviceconfig.xml
• or because the IAC service is not started automatically:
  Check the connection with the localhost (via Window->preferences->Agent Controller->hosts->Test connection).
  See this thread (and its follow up) for a working setup.

This thread might also be relevant.

---

For those On Linux:

It may be related to gcc version or libstdc++xx-glibcy.y version, as mentioned in bug 244213 or bug 240677

This blog post relates what kind of workaround is possible in his case. May be it could help here.

---

Extract:

A workaround for this is described in this blog post.

(Note: also described in this other blog post)

It's pretty straight forward: get a deb file libstdc++2.10-glibc2.2_2.95.4-27_i386.deb and install it with sudo dpkg ....

The problem is now that the workaround involves root actions.
First, one hasn't always the required root permissions to do so.
More importantly however, I don't like installing external debs and other stuff as root because it can interfere with the packaging system, pollute system directories and break things in ugly, or worse, unrecoverable ways.

I always install third party stuff (with which I mean things that are not available through the standard packaging system) in my home directory under ~/usr.
For example, I build autotools-managed software with the option --prefix=~/usr, so things end up in ~/usr/bin, ~/usr/lib, ~/usr/share, etcetera.

I managed to install the deb file described above also in ~/usr as follows.
First, I extracted the deb file to a temporary directory to get an idea of its contents:

dpkg -x libstdc++2.10-glibc2.2_2.95.4-27_i386.deb tmp/

This resulted in the following file tree:

tmp/
`-- usr
    |-- lib
    |   |-- libstdc++-3-libc6.2-2-2.10.0.so
    |   `-- libstdc++-libc6.2-2.so.3 -> libstdc++-3-libc6.2-2-2.10.0.so
    `-- share
        `-- doc
            `-- libstdc++2.10-glibc2.2
                |-- README.Bugs.gz
                |-- README.Debian
                |-- changelog.Debian.gz
                `-- copyright

So I just had to move the shared libraries libstdc++*.so to ~/usr/lib, or alternatively, extract the deb file directly int my home directory:

dpkg -x libstdc++2.10-glibc2.2_2.95.4-27_i386.deb ~/

One important missing piece of the puzzle is to make sure these shared libraries can be found at run time (or compile time in case you want to compile against them).
The trick is to set the LD_LIBRARY_PATH and LD_RUN_PATH environment variables, typically in your ~/.bashrc or ~/.profile startup scripts:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/usr/lib
export LD_LIBRARY_PATH
LD_RUN_PATH=$LD_RUN_PATH:~/usr/lib
export LD_RUN_PATH

And Eclipse TPTP profiling lived happily ever after. I hope.