In all of these cases, you should enter a bug report. Include the following information in the report:

+

In all of these cases, you should [http://bugs.eclipse.org report a new bug]. See [[FAQ How do I report a bug%3F]] for more information on reporting bugs. Include the following information in the report:

# What build of Eclipse you are using (see Help > About)

# What build of Eclipse you are using (see Help > About)

+

# What VM you are using (version and vendor). Use "java -version" to find out version information.

# What you were doing at the time of the deadlock (what dialog, wizard, editor, etc)

# What you were doing at the time of the deadlock (what dialog, wizard, editor, etc)

# Whether it is reproducible; if so, provide steps

# Whether it is reproducible; if so, provide steps

−

# Once the bug report is created, attach a stack trace use the "Create a New Attachment" link in bugzilla.

+

# Once the bug report is created, '''attach a stack trace''' (also known as thread dump), using the "Create a New Attachment" link in bugzilla.

−

If you are running on a Sun VM, the stack trace is typically just printed directly on the console. In this case, 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:

+

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 [[#Using jvisualvm (Java 6u7 or later)|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

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).

== Getting a stack trace on Windows ==

== Getting a stack trace on Windows ==

−

On Windows, the Java VM is typically started by an executable called javaw.exe. If you run with the java.exe executable instead, then a Java console window will appear while it is running. If you are interested in reporting bugs, it is useful to always run with a console open so you can obtain stack traces. Here is a typical command line for starting Eclipse using java.exe:

+

=== 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:

+

+

-vmargs

+

-Xms40m

+

-Xmx384m

+

'''-Dcom.sun.management.jmxremote'''

+

+

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

'''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:

eclipse -vm c:\jre\bin\java.exe -vmargs -Xmx300M

eclipse -vm c:\jre\bin\java.exe -vmargs -Xmx300M

+

+

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

+

+

eclipse -consolelog

+

+

or, even

+

+

eclipse -consolelog -debug

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

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 <i>attach</i>

+

it 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 [[http://www.latenighthacking.com/projects/2003/sendSignal/ SendSignal]].

+

+

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 [[http://www.microsoft.com/technet/sysinternals/utilities/ProcessExplorer.mspx 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 ==

== 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 [[#Using jvisualvm|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:

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

−

# Use the "ps" command to find out the process id (pid) of the Java VM

+

# Use the "ps" or the "jps" command to find out the process id (pid) of the Java VM

# Invoke "kill -3 <pid>" where <pid> is the process id of the Java VM

# 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

+

+

eclipse -vmargs -Dcom.sun.management.jmxremote

+

+

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) ===

+

+

*On command line, use <code>jps</code> to find the PIDs of Java processes and <code>jstack</code> to show the stack trace of Java processes: <code>jstack <pid></code>

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

+

+

#!/bin/bash

+

+

if [ $# -eq 0 ]; then

+

echo >&2 "Usage: jstackSeries <pid> [ <count> [ <delay> ] ]"

+

echo >&2 " Defaults: count = 10, delay = 1 (seconds)"

+

exit 1

+

fi

+

+

pid=$1 # required

+

count=${2:-10} # defaults to 10 times

+

delay=${3:-1} # defaults to 1 second

+

+

while [ $count -gt 0 ]

+

do

+

jstack $pid >jstack.$pid.$(date +%H%M%S.%N)

+

sleep $delay

+

let count--

+

echo -n "."

+

done

+

+

If your "sleep" command supports fractions of seconds by providing a floating point value, e.g. "0.1"

+

you may sample e.g. every half second using

+

+

jstackSeries <pid> 10 0.5

+

+

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

+

+

vimdiff file1 file2 file3 file4 # up to 4 files

+

kdiff3 file1 file2 file3

+

...

+

+

Another way to see what parts of the jstack trace are changing over time is to compare adjacent jstack trace

+

using context diff (-c option):

+

+

d_old=""

+

for d in jstack.13585.12171*

+

do

+

if [ -n "$d_old" ]

+

then

+

diff -c "$d_old" "$d"

+

fi

+

d_old="$d"

+

done

+

+

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 [http://www.latenighthacking.com/projects/2003/sendSignal/ 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 [http://www.eclipse.org/dsdp/tm 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

What VM you are using (version and vendor). Use "java -version" to find out version information.

What you were doing at the time of the deadlock (what dialog, wizard, editor, etc)

Whether it is reproducible; if so, provide steps

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

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).

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:

-vmargs
-Xms40m
-Xmx384m
-Dcom.sun.management.jmxremote

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

Using the Adaptj StackTrace tool

This is the preferred method when Java 6 is not available.
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")

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:

eclipse -vm c:\jre\bin\java.exe -vmargs -Xmx300M

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

eclipse -consolelog

or, even

eclipse -consolelog -debug

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 attach
it 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].

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.

Using kill -3 (UNIX only)

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

Use the "ps" or the "jps" command to find out the process id (pid) of the Java VM

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

eclipse -vmargs -Dcom.sun.management.jmxremote

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)

On command line, use jps to find the PIDs of Java processes and jstack to show the stack trace of Java processes: jstack <pid>

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