• Eclipse File Search Has Encountered A Problem Involving
• Eclipse File Search Has Encountered A Problem Encountered
• Eclipse File Search Has Encountered A Problem Out Of Sync

embed=425,349'Open Project' has encountered a problem. The project description file (.project) for 'MDKExample' is missing. This file contains important information about the project. The Project will not function properly until this file is restored. /embed I looked inside the Forge folder and there was an.project file. For example, below snippet will increase the eclipse heap size to 2 GB.-Xmx2048m Increase Permgen Space in Eclipse. If you are using below Java 8, then you might get OutOfMemoryError: Permgen space, just increase the permanent generation space available to Eclipse. Below is the configuration to increase permgen space to 512 MB in eclipse.ini file.

• Navigation
• Main Page
• Community portal
• Current events
• Recent changes
• Random page
• Help

• Toolbox
• Page information
• Permanent link
• Printable version
• Special pages
• Related changes
• What links here

• 3Components and Pre-Requisites
• 4Installation
  • 4.2Install PTP
• 5Updating from a previous release
  • 5.1Major releases
• 8Known Issues

Latest Version

The latest version of PTP is 9.1.0 and Photran is 9.1.0 (as of June 22, 2016)

A list of bugs fixed in 9.1.0 is available here.

For bugs fixes in later releases, see the bottom of New and Noteworthy for this release

Overview

This document describes how to install PTP and its pre-requisites. Documentation for using PTP is available from the Parallel Development User Guide.

The installation process for PTP depends on a number of factors, including the versions of software you have installed on your system, your operating system, and the types of target systems you want to use. The basic installation steps are:

1. Install Eclipse and PTP by doing one of the following:
   1. Full Install using the all-in-one Eclipse for Parallel Application Developers, or

Additional installation information is available on:

Note! The XSEDE 2013 tutorial contains detailed information about PTP 7.0.x and installing PTP on your workstation or laptop, including screenshots. You may wish to use the slides as a guide for installing Eclipse and PTP on your workstation or laptop. Then see below for information about installing components on your remote cluster as needed.

Components and Pre-Requisites

PTP is a set of plugins that extend the functionality of Eclipse. The following are the minimum requirements for PTP 9.0:

• Java 1.8 or later
• Eclipse 4.6 or later
• C/C++ Developer Tools (CDT) 9.0 or later

The client side of PTP (the system running Eclipse) is supported on the following platforms:

• Linux
• Mac OS X
• Windows

The server-side of PTP (the remote system used to launch/debug and host remote projects) is supported on the following platforms:

• Linux
• Mac OS X
• Unix (e.g. AIX)

For the parallel debugger to work, PTP must support the remote system for debug in the Target System Configuration / TSC. Currently PTP parallel debugger is implemented for:

• Generic TSCs:
  • Generic OpenMPI Interactive
  • Generic MPICH2 Interactive
  • Generic Remote Interactive
  • IBM Parallel Environment
  • IBM Platform LSF Interactive
  • IBM Platform MPI
• Specific system TSCs:
  • Trestles Torque OpenMPI Interactive

Server-side pre-reqs:

• git (if Synchronized projects are used) - version 1.7 or later - see https://bugs.eclipse.org/bugs/show_bug.cgi?id=410695
• Java (if RDT remote projects are used)
• Perl (for System Monitoring) - TBD: More Perl requirements for MPICH parallel debugging
• gdb (for Parallel Debugger)

Main Features

The PTP plugins are grouped into the following three main components:

Parallel Tools Platform (PTP) End-User Runtime

This feature contains the core PTP components, including all supported target system configurations, the Parallel Language Development Tools (PLDT), and the External Tools Framework (ETFw).

Fortran Development Tools (Photran)

This feature adds support for editing, compiling, and debugging programs written using the Fortran language.

Remote Services

This feature adds support for accessing remote systems. The remote services framework can be used independently of the other PTP components, and adds features such as remote file access, remote shell access, and a remote console.

Optional Features

The PTP optional features are a set of features that provide additional functionality not included in the core PTP components. Most of these features require the installation of third party software or specialized components of CDT. The PTP Optional Features are summarized in the table below:

Installation

There are two main steps to installing PTP. First you need to make sure that you have the correct version of Java on your client system. The second step is to download and install the PTP plugins. These steps are outlined in more detail below.

Install or Update Java

Ensure that a Java Runtime Environment (JRE) version 1.8 or higher is installed. This can be done with the command:

In addition an IBM, Sun, or equivalent JRE is required; The gcj-based Java shipped with most Linux distributions does not work with Eclipse. If in doubt, run the above command and check if there is a reference to gcj. If you are using the Linux operating system, download and install either the Sun Java Runtime Environment or the IBM Java Runtime Environment. See also Installing Java for use with Eclipse and PTP.

Install PTP

There are two options for installing PTP: Full install or install into an existing Eclipse. A full install downloads and installs a copy of Eclipse that contains pre-installed PTP plugins. This is the simplest option. Install into an existing Eclipse is useful if you already have Eclipse installed and you just want to add the PTP functionality. Both methods are described in more detail below.

Full Install

This is the simplest, easiest, and most reliable way to install PTP, and it is recommended for most users.

1. Download the 'Eclipse for Parallel Application Developers' package from http://eclipse.org/downloads/
2. After downloading and extracting Eclipse (zip or tar file), there's nothing else to the installation process from the Eclipse side. In the extracted folder, simply run the eclipse executable file. It will ask for a workspace location; the default is fine.
   • See also Updating from the Parallel Package to a more recent release below
   • Multi-user installs: Note that the default install assumes that the user has write access to the location where Eclipse in installed (unzipped or un-tarred). See multi-user install information for other scenarios.

Install into an existing Eclipse

This option assumes that you have already installed Eclipse and are familiar with the Eclipse installation process.

We recommend starting with either:

• 'Eclipse Standard' - (previously known as Eclipse Classic) if you also plan to do Java and/or plugin development, or
• 'Eclipse IDE for C/C++ Developers' - only includes support for C/C++, which is simpler and smaller

Using the table above, choose the components you wish to install, and note the pre-requisites required.

• If you are unsure, just choose 'Parallel Tools Platform (PTP) End-User Runtime'

Make sure Eclipse is running, then follow the steps below:

1. Open 'Help > Install New Software..'
2. From the 'Work with:' drop down, choose 'Neon - http://download.eclipse.org/releases/neon'
   • See below for possible more recent updates to PTP
3. Open the 'General Purpose Tools' category
   • Check the PTP components you require
   • If you are unsure, just choose 'Parallel Tools Platform (PTP) End-User Runtime'
4. If any of your selections require CDT as a pre-requisite:
   • Open the 'Programming Languages' category
   • Check 'C/C++ Development Tools'
5. To add Fortran support:
   • Open the 'Programming Languages' category
   • Check 'Fortran Development Tools (Photran)' (See the Photran 9.1 Online documentation for more information on installing and using Photran)
     • Update above URL for Neon Photran docs
6. Select the 'Finish' button and follow the prompts
   • You should restart Eclipse when prompted.

Customizing the PTP Debugger

Prior to launching the parallel debugger for the first time on a target system, an executable called the SDM will be automatically copied to the target.

In certain situations you may wish to use a different version of the SDM, or install the SDM in a different location (e.g. a shared directory).

The SDM source code and pre-built binaries are available from the download site. You can use these to customize your installation in any way you wish:

1. Download ptp-sdm-9.0.x.zip from the PTP downloads page
2. Copy the sdm zip file to the target machine
3. Unzip the sdm zip file into a temporary location
4. Change to the sdm directory

At this point you can either use one of the pre-built binaries, located in the org.eclipse.ptp.<os>_9.0.x.yyyymmddhhmm directories or build your own sdm from source (<os> corresponds to an operating system type, and 9.0.x.yyyymmddhhmm corresponds to the numeric version and build date of the PTP release.)

To build from source:

1. Change to the org.eclipse.ptp.debug.sdm_9.0.x.yyyymmddhhmm directory
2. Run the command:

This should build the sdm executable.

PTP assumes a default location of the sdm is /usr/local/bin. If desired, however, you can copy the sdm executable to any convenient directory. When you configure a debug launch configuration, you will need to select the sdm executable in this directory.

Installing Open MPI

If you do want to build OpenMPI yourself, here are instructions based on building OpenMPI 1.4.2. See the Open MPI FAQ for more information on building and installing Open MPI.

1. Download the openmpi-1.4.2.tar.gz file
2. Untar it using the command tar -xzvf openmpi-1.4.2.tar.gz and cd to the directory it creates
3. Run ./configure
   • The default installation location is /usr/local
   • To install into a different location, e.g. /usr/local/openmpi1.4.2, use the command:
     • ./configure --prefix=/usr/local/openmpi-1.4.2
   • To add the Fortran bindings (test): add --enable-mpi-f77 and/or --enable-mpi-f90
   • Then don't forget to modify PATH, etc:
     • export PATH=/usr/local/openmpi-1.4.2/bin:/usr/local/bin:$PATH
     • export LD_LIBRARY_PATH=/usr/local/openmpi-1.4.2/lib:/usr/local/lib
   • If you have problems with Fortran bindings (e.g. Snow Leopard), you can disable this by adding --disable-mpi-f77 to the configure script
4. Build and install with sudo make install

Then to check your install:

1. ompi_info should return version info including version that matches what you installed above.

Build and run a small MPI test case, for example: testMPI.c

1. mpicc -o testMPI testMPI.c
2. mpirun -np 4 testMPI

Updating from a previous release

Major releases

If you are updating to PTP 9.x from a previous major release (e.g. 8.0, 7.0, etc.) it is recommended that you start with a completely new installation of Eclipse and a new workspace. Existing projects can be imported into the workspace using one of the available import wizards (File > Import).

Convert workspaces created under PTP 7.0

If you have synchronized projects created under 7.0, please use the following procedure to update them in a 9.x workspace.Since synchronized projects can exist for other types of Eclipse projects besides C/C++/Fortran, the synchronized information is kept entirely differently in PTP 9.0.

• Assure the project is synchronized and all local content is on the server as well
  • if you have local content that you have filtered and not sync'd to the remote system, back it up elsewhere.
• Delete the project from eclipse (right mouse on project, Delete, check the box for Delete project contents on disk)
• Create a new synchronized project (File > New > Other > Remote > Synchronized C/C++ project or Synchronized Fortran project) and point to the directory on the remote system where the original is located
• If you have any local content not sync'd to the remote system, paste it back into the project now and update the Sync filters to prevent it from syncing again.

Updating from the Parallel Package to a more recent release

The normal way to update PTP is to use Help > Check for Updates, however there are two reasons this may not report any updates are available, even when a PTP update exists.

1. If you installed the Eclipse for Parallel Application Developers or some other Eclipse build
   • Because, unless you installed a subsequent update from the PTP-specific update site, 'Check for Updates' only looks at the site(s) you installed initially from
2. If the PTP update site is not enabled in the update manager

If 'Check for Updates' does not report any updates, follow the steps below. Note that these steps only need to be done once, and 'Check for Updates' should work for subsequent releases.

Installing a new PTP build or release

1. Open Help > Install New Software..
2. Click on 'Available Software Sites'
3. Locate the PTP-specific update site and make sure it is checked. If it doesn't exist, create a new one.
   • The PTP update site URL is http://download.eclipse.org/tools/ptp/updates/neon
4. Click OK to return to the main dialog
5. If you are using the Eclipse for Parallel Application Developers:
   • Select the PTP update site from the 'Work with:' dropdown
   • Decide how much you want to update/install:
     • Simplest: check the box next to each category to update everything
     • Or, to update only the currently-installed PTP features:
       • Open each category and check the box next to the items that are already installed (the icon shows two arrows). If the icons are grey, the update is already installed for that item.
       • 
         gray plug icon - feature already installed and up to date;
         two arrows - feature needs to be updated;
         color plug - feature is not installed
   • Click Next and follow the instructions (Next, Next, Finish, accept license).
6. If you are NOT using the version of PTP from your original Eclipse for Parallel Application Developers, that is, if you installed from http://download.eclipse.org/tools/ptp/updates/neon directly since then, then updating should work:
   1. Click Cancel to quit the update manager
   2. Select Help > Check for Updates
   3. Follow the instructions

Once you install from http://download.eclipse.org/tools/ptp/updates/neon, either initially, or on top of Eclipse for Parallel Application Developers, the Help > Check for Updates will work after that to update from this site as well.

Test your installation

The easiest way to test your installation is to create and run an MPI application.

1. Start Eclipse. (You may need to use the -clean parameter to force it to recognize new features and plug-ins).
2. Switch to the C/C++ perspective (Window > Open Perspective > Other..)
3. Create a small MPI C project.
4. Create a launch configuration (Run > Run Configurations..) and create a run configuration for a Parallel Application.
   • Fill in the information for the particular type of target system configuration
   • For example, for an Open MPI application this includes (but may not be limited to):
     • On Resources tab, select Number of processes
     • On Application tab, select your Project for Parallel Project, and the executable for Application Program.
     • On Debugger tab, find the sdm executable that you build from the command line during the installation process as the 'Path to debugger executable'
5. Launch the application.

More details on using PTP can be found in Help > Help Contents. Click on 'Parallel Tools Platform User Guide'.

The PTP help is also available online.

Troubleshooting

1. I have an OTP token that's required for use with the my remote system. Can I use this when creating synchronized C/C++ projects and/or the resource manager?

Solution: Use the OTP password but avoid saving the password with any of the dialogs. If you skip the password in dialogs that prompt for both username and password, you'll get a separate password prompt. Use your OTP password there.

2. I created a resource manager but I entered the wrong username/password. How do I change these?

Solution: Open Connection preferences by selecting 'Preferences > Remote Development > Connections'. In the view click on the name of the connection you used in the resource manager configuration and then 'Edit'. Note that a connection must be stopped in order to edit it. Of course, if the username/password is wrong, it probably isn't running.

3. The parallel debugger does not start (may be stuck in 'Upload file' or 'Waiting for connection..'.)

Solution: There are many reasons that this could be happening:

• Check that you can run the MPI program successfully (non-debug), both from the command line, and from within Eclipse
• Check that you have compiled the application for debugging with -g
• Check that the debugger session address on the 'Debugger' tab of the launch configuration is set to 'localhost'
• If you have installed your own sdm on the remote machine, check that the path is correct on the 'Debugger' tab in the launch configuration
• See Known Issues - Debugger below

If still have a problem, ask on ptp-dev mailing list, and be sure to list your platform, PTP version, version of Open MPI (or other system), and what the debugger session address is set to.

4. The parallel debugger will not honor breakpoints; dialog reports 'Writing routing file' and 'Master SDM Control has encountered a problem' and 'Error completing debug job launch. Reason: Cannot connect to debugger'

Solution: Make sure you have built sdm for your platform (either local or remote). See the above section on Customizing the PTP Debugger. In the debug launch configuration dialog, make sure you have selected the sdm executable that you built.

5. I've created an Open MPI resource manager, but it fails to start with the message 'Unable to determine version of Open MPI. Please check discover command is correct.'

Solution: If the resource manager is local, see troubleshooting local resource managers below. If the resource manager is remote, then it is probably an issue with your PATH or LD_LIBRARY_PATH (or both) on the remote machine. Try running the command ssh remote_host ompi_info -a --parseable. If the ompi_info command is not found, then you need to set your PATH correctly on the remote machine. If you see a message like 'ompi_info: error while loading shared libraries: libmpi.so.0: cannot open shared object file: No such file or directory' then you also need to set the LD_LIBRARY_PATH on the remote machine.

6. Eclipse is unable to start a local resource manager.

Solution: This is usually because your PATH is not being picked up by Eclipse. Most window systems do not get their paths from the shell, so when you launch Eclipse it will have the wrong PATH set. Consult the documentation on your window system for details on how to set the path, or alternatively, launch Eclipse directly from a shell. See also this PTP FAQ item.

7. Every time I run an application, all the projects in my workspace build.

Solution: Open the Eclipse preferences. Go to 'Run/Debug' and click on the 'Launching' preference. Uncheck 'Build (if required) before launching'.

8. I only see one node when I start an Open MPI resource manager, how do I simulate multiple nodes on a single machine?
Solution: Edit /usr/local/etc/openmpi-default-hostfile (or wherever you installed Open MPI) and add lines containing

node1 ..

Edit /etc/hosts and add a localhost entry for each name you added to the openmpi-default-hostfile:

Edit /usr/local/etc/openmpi-mca-params.conf and add the following to the end:

9. I want to alter the hostfile information but don't have root access.

Solution: Create a file, say 'hostfile' in your home directory containing the hostnames of the nodes. Then set the'OMPI_MCA_orte_default_hostfile' environment variable to '$HOME/hostfile'. You'll need to do this in your .bashrc or .tcshrc (the one which is executed when a new shell is created.) Using .bash_profile or .login won't work.

10. How do I launch eclipse?

Solution: Normally just run the eclipse executable - however, you may want to try this from a command line instead of from a 'shortcut' - some OS's or windowing systems do not properly send the environment information. And, some OS's send the wrong info from the command line. Your mileage may vary.

11. Why are there XML tags in my parallel program output when I run my OpenMPI program in PTP?

Solution: XML tags should be gone in OpenMPI version 1.3.4 and later

12. Why can't I set a normal (non-parallel) CDT breakpoint in my editor? (Version 4.0.0)

Solution: The Remote C/C++ Editor does not currently support CDT breakpoints. Open the C/C++ Editor on the file instead by right-clicking on the file and selecting 'Open With > C/C++ Editor. This problem should be addressed in 4.0.1. Update your version of PTP to 4.0.1 or later.

Known Issues

Launching

1. My launch seems to get stuck at 'Opening connection' when starting.

Connecting to a remote system from Eclipse on some client operating systems (in particular Fedora Core 11) generate a Kerberos authentication request. Check the command line where you started Eclipse for a Kerberos prompt. Enter your login name and password when requested.

Your operating system documentation may provide information on how to disable this request from being generated.

2. A 'Secure Storage' dialog is seen when starting Eclipse on Linux.

Eclipse stores usernames/passwords in secure storage. On some systems, a password (usually your login password) must be entered to unlock this storage before Eclipse can access it. Check your operating system documentation for ways to disable this prompt.

Debugger

1. The debugger gets stuck at 'Upload file'

When the debugger launches onto a remote system, it attempts to make a connection back to your local machine running Eclipse. If you have the 'SSH Tunneling' option enabled on the resource manager, then this connection will be made over the main ssh connection using an ssh tunnel. For this to work, your remote target sshd configuration needs to enable the 'GatewayPorts' option. See the sshd_config(5) for more information on this option.

Workaround: If you are not able to change the sshd configuration on the remote target, the only option is to not use tunneling. This requires direct access from the remote target to your local Eclipse client machine (i.e. you from the remote target system, you should be able to use 'ping <local_client_host>'.) Also, you'll need to disable the firewall on the local client machine so that the incoming connection is permitted.

2. The debugger gets stuck at 'Waiting for connection'

The debugger requires a filesystem that is shared across all nodes in the cluster in order to distribute routing information. If this routing file doesn't exist, then one or more of the debugger server processes will appear to hang.

Workaround: In this situation, the routing file must be manually distributed in order for the server processes to proceed.

This limitation will be addressed in a future version of the debugger.

3. Accelerator keys (F5, F6) operate on the current process selected in Debug view.

There is currently no way to use these keys for the Parallel Debug view.

4. Debugger won't connect; breakpoints don't work; error dialogs

Make sure you've built sdm for your target system. See the section on troubleshooting above - items about debugger.

Remote Development Tools (RDT)

1. The Remote C/C++ Editor is used by default for local files

RDT currently provides a framework for developing C/C++ programs on remote machines. Although it is our intention that RDT work seamlessly with CDT and other Eclipse plug-ins, there is a problem with the Eclipse platform which hinders interoperabilty between base CDT and RDT, namely that the Remote C/C++ Editor provided by RDT is always used by default for editing C/C++ files.

Workaround: Although this issue can be worked around by manually selecting the CDT editor (Context Menu >Open With >C/C++ Editor) when you are working with a local CDT project, it can be tedious having to do this for every single file you open. As such, we recommend that you install RDT into an Eclipse installation which you do not intend to do local C/C++ development with. Future versions of Eclipse and RDT should better support local development.

2. Unable to set CDT breakpoints in the Remote C/C++ Editor

This issue is similar to the previous problem. Right-click on the file and select Open With > C/C++ Editor. Note also that debugging remote projects with the CDT debugger has not been tested. It is likely that problems will occur if the debugger assumes files reside locally, but are actually located on a remote machine. Use at your own risk.

3. Remote projects are always closed when Eclipse restarts

When you exit and restart Eclipse, all your remote projects are closed. This happens because the .project file is on the remote server and when eclipse starts there is no connection yet, so eclipse thinks the .project file is missing and closes the project.

Workaround: To work around this issue, simply reopen your projects after the connection to the remote machine has been re-established.

4. Remote editors are not properly restored on Eclipse restart

If you leave remote editors open upon closing down the workbench, when you restart, the editors will not be properly initialized, showing a 'resource not found' error. Closing and reopening the editor will not alleviate the problem. This problem occurs because on startup of the workbench, the remote connection is not yet established, and hence opening the editors fails.

Workaround: To work around this problem, close all editors opened on remote resources before shutting down the workbench. If the problem occurs, you can alleviate it by closing the affected editors and restarting the workbench.

5. Quick Type Hierarchy does nothing

Invoking Quick Type Hierarchy from the editor context menu does not currently do anything.

Workaround: Use 'Open Type Hierarchy' instead to open the Type Hierarchy View for an alternate method of viewing type hierarchy information.

Parallel Language Development Tools (PLDT)

1. Analysis of parallel applications located on a remote server doesn't seem to work

Note that not all PLDT features are tested and verified for running with RDT at this time.

Since 4.0.3, finding artifacts (MPI, OpenMP, UPC) does work on remote projects.

Workaround: To use other PLDT analysis features, use a local CDT project, instead of a remote project.

C/C++ Build Issues

1. I get the error 'The Open MPI wrapper compiler was unable to find the specified compiler gcc in your PATH.' when I build an MPI program (e.g. created with the Hello MPI World new project wizard).
• The PATH variable may not be getting communicated to CDT correctly. Copy the contents of your PATH variable in the clipboard, and open the Project Properties, c/c++ build, Environment, add var: PATH and paste in the PATH from cmd line
• The ptp_ibmpe_proxy and ptp_ibmll_proxy proxies for the IBM PE and IBM LoadLeveler resource managers do not work with LoadLeveler. Messages may be displayed stating that libllapi.so could not be loaded on Linux systems.
• Depending on the version of LoadLeveler installed, libllapi.so may be a 32 bit shared library or a 64 bit shared library. This can be determined by locating libllapi.so in /opt/ibmll/LoadL. For 32 bit versions, it will be in /opt/ibmll/LoadL/full/lib, /opt/ibmll/LoadL/scheduler/lib, or /opt/ibmll/LoadL/so/lib. For 64 bit versions, libllapi.so will be in the corresponding lib64 directories. You should set the CFLAGS environment variable to contain either the -m32 or -m64 flags before invoking the BUILD script, for instance CFLAGS=' -m64' sh BUILD configure

Feature Descriptions

• Navigation
• Main Page
• Community portal
• Current events
• Recent changes
• Random page
• Help

• Toolbox
• Page information
• Permanent link
• Printable version
• Special pages
• Related changes
• What links here

Say you've encountered a problem in Eclipse that has one of the following symptoms:

• A long pause where the GUI does not redraw or respond
• A deadlock or freeze where the GUI stops responding indefinitely
• CPU pegged at 100% indefinitely
• A modal dialog that won't close

In all of these cases, you should report a new bug. See FAQ How do I report a bug? for more information on reporting bugs. Include the following information in the report:

1. What build of Eclipse you are using (see Help > About)
2. What VM you are using (version and vendor). Use 'java -version' to find out version information.
3. What you were doing at the time of the deadlock (what dialog, wizard, editor, etc)
4. Your JVM configuration: how much memory is being allocated to the JVM
5. Your machine configuration: how much RAM, how much RAM is free, was it swapping
6. Whether it is reproducible; if so, provide steps
7. Once the bug report is created, attach a stack trace (also known as thread dump), using the 'Create a New Attachment' link in bugzilla.

Regardless of how you get your stack trace, please paste the contents into a file and then attach the file. Stack traces pasted directly into bugzilla look very ugly. On an IBM VM, the stack trace is written to a file in the working directory of the Java process. Typically this will be found in the eclipse install directory. The steps for producing a stack trace vary according to what operating system you are using.

Recommended Method for getting the thread dump:

When you can run Eclipse with a recent Sun Java 6 or higher JVM, using the jvisualvm method is recommended, since it is easy and allows generating a heap dump at the same time. In general, it is helpful to always run Eclipse as

Eclipse File Search Has Encountered A Problem Involving

See MemoryAnalyzer#Getting_a_Heap_Dump for more details about heap dumps, which help diagnosing out of memory errors. The heap dump will be large (up to 200 MB compressed), but very helpful diagnosing the issue.

See below for other methods acquiring a thread dump (aka stack trace).

• 1Getting a stack trace on Windows
• 2Getting a stack trace on other platforms
  • 2.4Using jps / jstack (requires JDK 1.6 or later)
• 3Remote Diagnosis

Getting a stack trace on Windows

Using jvisualvm

The Java Visual VM tool is shipped as part of JDK 1.6.0_07 or later. It can create thread dumps of programs run with Java6. Programs run with Java5 can also be dumped when they have been started with the -Dcom.sun.management.jmxremote system property. This is best added as a separate line in eclipse.ini anywhere after the -vmargs argument:

'The jvisualvm output is better than in the Java5 jconsole tool, so when you have Java6 this is now the preferred method.

1. Launch the JDK's jvisualvm tool.
2. Connect to Eclipse by double clicking the process.
3. Switch to the Threads tab.
4. Click the 'Thread Dump' button in upper right.

Using the Adaptj StackTrace tool

This is the preferred method when Java 6 is not available.

Note:As of now, the URL specified below is not accessible and it's not known whether this will be available anytime soon. Therefore, it is recommended to use any of the other given methods.

Given that your Eclipse is currently hanging in a deadlock, best use the tool found at the adaptj home page, since it requires no preparations:

• Follow the link and select button 'Launch' (press 'OK' to 'Run as a Java WebStart Application')
• Select menu Process > Select
• In the combo box 'Process ID' press the '..' button, select 'eclipse.exe' application and click OK
• Pick menu Process > Thread Dump
• File > Save As (enter some name e.g. C:myThreadDump.txt)

Take Care: The generated thread dump also contains the JVM's environment including the commandline that was used for starting Eclipse. Take care not to expose any sensitive information (like keyring password) before giving outsiders access to your file.

Attach that file on bugzilla when filing a bug that describes how you got the deadlock.

Using eclipse -consolelog

As an alternative, if you are interested in reporting bugs, it is useful to always run with a console open so you can obtain stack traces. If you are using Eclipse 3.3 (Europa) or greater on Windows, you can simply run with eclipsec.exe to obtain a console window. On Eclipse 3.2 or older, you will need to specify java.exe as your VM on the command line. Here is a typical command line for starting Eclipse using java.exe:

Or, if you normally use your system's default java VM, you can use

or, even

Once you have a Java console window, you can obtain a stack trace by simply hitting Ctrl+Break when the console window is active.

Note: its recommended you increase the 'buffering size' of the console window, to a wide width such as 300 (default is usually 80) and perhaps even a long length (such as 3000) so there's plenty of room for a well formatted stack trace. Then, preferably, copy/paste the stack trace to a text file and attachit to a bugzilla, so its formatting is preserved.

Debugging as an Eclipse Application

The same is possible if you start Eclipse using the 'Eclipse Application' launch configuration (ie. from another instance of Eclipse). The problem here is that you don't have a console in which to press Ctrl+Break. You will need a tool like [SendSignal].

Eclipse File Search Has Encountered A Problem Encountered

SendSignal can send a break to any process and you will get the stack dump in the Eclipse console of the controlling instance. This has the additional advantage that the buffer will probably be big enough. The tool needs the PID (process id) which is not that simple to find on Windows. Either you use a tool like [Process Explorer]. There, you can see the right process as a child of your Eclipse process.

If you can't do this, you'll have to use the Windows Task Manager. The first step is to make the PID visible. Select the 'Process' tab and then 'Select columns..' in the View menu. Make sure PID is selected. To determine which PID is the one you're looking for, sort the processes by name and watch the running Java processes (javaw.exe). Look again after you started the Eclipse process. There should be a new process, now.

Note: It doesn't do much harm if you send the signal to the wrong, process. You just won't see the thread dump.

Getting a stack trace on other platforms

This applies to Unix, Linux, and Mac OS X systems.

Using jvisualvm (Java 6)

When you can run Eclipse with a Java 6 JVM, this is the preferred method.

See the Windows Instructions above for how to use it.

Using kill -3 (UNIX only)

On all Unix-based platforms, the steps for producing a stack dump are the same:

1. Use the 'ps' or the 'jps' command to find out the process id (pid) of the Java VM
2. Invoke 'kill -3 <pid>' where <pid> is the process id of the Java VM

A thread dump will be printed on the console where you started Eclipse.Since it may be long, in order to Copy & Paste it, it might be necessary to scroll and/or reduce the font size (xterm: right-click > font size > unreadable).

Using jconsole (requires JDK 1.5 or later)

This works on any OS, provided that the debuggee (Eclipse) has been launched with

which is a non-intrusive, recommended argument for any Eclipse based program in order to facilitate diagnostics.

• Launch the JDK's jconsole tool from commandline. You can attach to the Java Process and inspect / copy the backtrace of any interesting Thread separately
• This allows introspection to any single Thread, but not getting a complete backtrace; the 'Detect Deadlock' functionality works rarely

Using jps / jstack (requires JDK 1.6 or later)

Eclipse File Search Has Encountered A Problem Out Of Sync

• On command line, use jps -v to find the PIDs of Java processes and jstack <pid> to show the stack trace of Java processes.
• Supported starting JDK 5 for UNIX / JDK 6 for Windows

Example session:

Here 32308 and 8824 are PIDs of Java processes. 8824 is jps itself and is of no interest for us. 32308 is and Eclipse process judging from presence of org.eclipse.equinox.launcher in its command line. Jstack command saves stack trace of Eclipse process in a file /tmp/jstack.txt, attach the file to bug report.

jstackSeries -- jstack sampling in fixed time intervals (tested on Linux)

This simple shell script takes several jstack snapshots in fixed time intervals:

If your 'sleep' command supports fractions of seconds by providing a floating point value, e.g. Zona zamfirova 2 deo online. '0.1'you may sample e.g. every half second using

To compare the results you may use interactive diff viewers, e.g.

Another way to see what parts of the jstack trace are changing over time is to compare adjacent jstack traceusing context diff (-c option):

Here, the result shows only the places where the jstack trace changes from file to file.

Remote Diagnosis

If you want to get a Thread Dump from Eclipse in a situation where some UI interaction is required, you'll need a separate machine for making the Thread dump: on the 'target' machine, use Eclipse like you normally would (e.g. open a context menu) and from the 'debug' machine initiate the Thread dump.

On UNIX machines, the 'kill -3' method will work from remote logins as well; on Windows machines, if you have some tool to log in remotely, you can use SendSignal in a similar way, or you use the jps/jstack method if you have JDK 1.6 or later. Remote login to Windows works with Eclipse RSE through a Windows DStore Daemon, for instance. Alternatives are setting up an sshd or telnetd with Cygwin or Microsoft SFU.

Remote Debug Connection

Recommended Method if you can afford starting with -Xdebug and reproduce your issue with -Xdebug

• On target machine, launch
  eclipse -vmargs -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
• On debug machine, launch Eclipse, create a new Debug Launch of type 'Remote Java Application' and enter the hostname / port number (5005)
• On remote debug session, suspend VM at the time you want the thread dump
• In debug view, expand all interesting stack frames, select all, right-click > Copy Stack

jconsole remote connection (requires JDK 1.5 or later)

• On target machine, launch
  eclipse -vmargs -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
• On debug machine, launch jconsole, connect to remote hostname:12345
• Use different port number if 12345 is taken
• This allows introspection to any single Thread, but not getting a complete backtrace; the 'Detect Deadlock' functionality works rarely

jstack remote (UNIX only, requires JDK 1.5 or later)

• On target machine, launch jsadebugd
• On debug machine, launch jstack with appropriate parameters for remote target

Other options

For yet other options to get a thread dump, see Mylyn Contributor Reference#Debugging

For diagnosing and getting stack traces for deadlocks using the Eclipse debugger see Deadlock detection with Eclipse