Jump to: navigation, search

Difference between revisions of "How to report a deadlock"

(Added steps to create a thread dump from within Eclipse.)
Line 35: Line 35:
 
well formatted stack trace. Then, preferably, copy/paste the stack trace to a text file and <i>attach</i>
 
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.
 
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 ==

Revision as of 04:27, 19 February 2007

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. Whether it is reproducible; if so, provide steps
  5. Once the bug report is created, attach a stack trace 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:

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:

  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

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

  1. Use the "ps" 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