Community
Participate
Working Groups
Steps to reproduce: I'm using eclipse 3.0.0 build 200310101454. In a new project, select a project sub-directory and right-click, select new->file and supply a filename (e.g. tmp.txt). Press 'finish'. Eclipse appears to be completing the task, but never completes. Clicking on cancel does not do anything. If you attempt to close the window, eclipse reports that the file wizard is in progress and you need to 'cancel' the current operation before you can close. I then have to use xKill to get rid of eclipse and restart it. As a workaround, I'm creating the files outside of eclipse and then just editing them through the workbench. It only appears to affect 2nd level directories/files. I've successfully created files and directories in the project root. I've included the log file output below. I hope that it helps. This is my 1st eclipse bug report, if there is anything else that would help, please let me know. Thanks, James !SESSION Oct 20, 2003 11:35:18.256 --------------------------------------------- java.version=1.4.1_04 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_ZA Command-line arguments: -os linux -ws gtk -arch x86 -data /home/james/public_html -install file:/usr/local/eclipse/ !ENTRY org.eclipse.core.resources 4 2 Oct 20, 2003 11:35:18.259 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.core.resources". !STACK 0 org.eclipse.swt.SWTException: Invalid thread access at org.eclipse.swt.SWT.error(SWT.java:2369) at org.eclipse.swt.SWT.error(SWT.java:2299) at org.eclipse.swt.dnd.DND.error(DND.java:230) at org.eclipse.swt.dnd.DND.error(DND.java:181) at org.eclipse.swt.dnd.Clipboard.checkWidget(Clipboard.java:131) at org.eclipse.swt.dnd.Clipboard.getAvailableTypes(Clipboard.java:281) at org.eclipse.ui.views.navigator.PasteAction.updateSelection(PasteAction.java:220) at org.eclipse.ui.actions.SelectionListenerAction.selectionChanged(SelectionListenerAction.java:208) at org.eclipse.ui.views.navigator.RefactorActionGroup.updateActionBars(RefactorActionGroup.java:139) at org.eclipse.ui.views.navigator.MainActionGroup.handleResourceChanged(MainActionGroup.java:107) at org.eclipse.ui.views.navigator.MainActionGroup$1.resourceChanged(MainActionGroup.java:74) at org.eclipse.core.internal.events.NotificationManager$2.run(NotificationManager.java:218) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1018) at org.eclipse.core.runtime.Platform.run(Platform.java:461) at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:211) at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:118) at org.eclipse.core.internal.resources.Workspace.broadcastChanges(Workspace.java:153) at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:852) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1562) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1572) at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:85) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:101) !ENTRY com.xored.xws.php.launching 4 4 Oct 20, 2003 11:39:13.267 !MESSAGE Bad installation at: /usr/local/eclipse/plugins/com.xored.xws.bundled.php-core.win32_4.3.1/php.exe
The log entry is unrelated to the freezing. I have reopened bug 42176 for this invalid thread access problem. When eclipse is hung, try sending "kill -3" to the java process. This should produce a stack dump file in the pwd that will tell us why it is hanging. Please attach this dump file to the bug report (using the "create new attachment" button near the top of this page). I am not able to reproduce the problem with that Linux build (using GTK).
Created attachment 6490 [details] stack dump
Thanks for the stack trace. Can you attach one more trace just to be sure the problem is consistent? With only one data point a deadlock and an infinite loop look much the same. When it is in this state, does the process continue to consume any CPU? The command line utility called "top" can be used to see the most active proecesses. Thanks again for following up with more information so quickly.
I've attached a stack dump as requested, but I'm not sure if it is what you need. If there are any other details, please let me know.
In answer to the questions: When it is in this state, does the process continue to consume any CPU? 1. Here is a copy from 'top'. as you can see, eclipse and X are consuming pretty much all the available cpu. 5865 james 17 0 80332 78m 18m R 53.2 13.1 0:40.63 java 1711 root 17 0 86828 52m 9.9m R 39.4 8.7 44:31.33 X This is the view from 'top' a few minutes(!) after creating the 'hanging' condition. I've also prepared another stack trace. which I will attach.
Created attachment 6493 [details] another stack trace
The output from top is a little useless without the solumn headings. The same info with the column headings ... PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ Command 5865 james 17 0 80332 78m 18m R 53.2 13.1 0:40.63 java 1711 root 17 0 86828 52m 9.9m R 39.4 8.7 44:31.33 X
Can I get an opinion from SWT for these stack traces? The trace in comment #6 is the simplest variant. Here is what's going on: - background thread (ModalContextThread) is trying to do a syncExec. It has added the RunnableLock to the queue and is waiting for it to be served - the main thread is in the event loop, but it never processes the deferred event posted by the background thread. The first stack trace (comment #2) looks a bit different. In this case the main thread has exited the event loop, but is then stuck in Display.update and never returns (the user is reporting that the window never closes). CPU usage remains high, with both X and java processes busy.
This seems to be the same bug as Bug#36698. James, could follow the instructions in that bug (check your GTK version, etc) and confirm if it is the same bug? Thanks! Silenio
Also, check Bug#45002.
Timed out, assuming that this is a dup of bug 36698 ; if you still see this problem happen while using a gtk version that is confirmed to not have the treeview peg bug (as specified in bug 36698) then please reopen. *** This bug has been marked as a duplicate of 36698 ***
