Community
Participate
Working Groups
I20061114-1636 TextSearchVisitor.search(IFile[], IProgressMonitor) creates a new Job and notifies the progress monitor in another thread. This causes problems when the progress monitor expects to be called in the UI Thread. E.g. when I rename a type with the "rename in editor" feature and enable "Update fully qualified names in non-java files", I get an error dialog and the exception below. The problem is that RenameLinkedMode.doRename(..) starts the refactoring with the workbench window as context and the StatusLine apparently cannot handle progress updates from other threads. !ENTRY org.eclipse.core.jobs 4 2 2006-11-15 14:59:05.061 !MESSAGE An internal error occurred during: "Search progress polling". !STACK 0 org.eclipse.swt.SWTException: Invalid thread access at org.eclipse.swt.SWT.error(SWT.java:3407) at org.eclipse.swt.SWT.error(SWT.java:3330) at org.eclipse.swt.SWT.error(SWT.java:3301) at org.eclipse.swt.widgets.Display.error(Display.java:1001) at org.eclipse.swt.widgets.Display.checkDevice(Display.java:661) at org.eclipse.swt.widgets.Display.getSystemColor(Display.java:1991) at org.eclipse.jface.action.StatusLine.updateMessageLabel(StatusLine.java:640) at org.eclipse.jface.action.StatusLine.setMessage(StatusLine.java:530) at org.eclipse.jface.action.StatusLine.setMessage(StatusLine.java:518) at org.eclipse.jface.action.StatusLine.subTask(StatusLine.java:599) at org.eclipse.jface.action.StatusLineManager$1.subTask(StatusLineManager.java:207) at org.eclipse.core.runtime.ProgressMonitorWrapper.subTask(ProgressMonitorWrapper.java:156) at org.eclipse.core.runtime.SubProgressMonitor.subTask(SubProgressMonitor.java:170) at org.eclipse.core.runtime.ProgressMonitorWrapper.subTask(ProgressMonitorWrapper.java:156) at org.eclipse.core.runtime.SubProgressMonitor.subTask(SubProgressMonitor.java:170) at org.eclipse.core.runtime.ProgressMonitorWrapper.subTask(ProgressMonitorWrapper.java:156) at org.eclipse.core.runtime.SubProgressMonitor.subTask(SubProgressMonitor.java:170) at org.eclipse.core.runtime.ProgressMonitorWrapper.subTask(ProgressMonitorWrapper.java:156) at org.eclipse.core.runtime.SubProgressMonitor.subTask(SubProgressMonitor.java:170) at org.eclipse.core.runtime.ProgressMonitorWrapper.subTask(ProgressMonitorWrapper.java:156) at org.eclipse.core.runtime.SubProgressMonitor.subTask(SubProgressMonitor.java:170) at org.eclipse.search.internal.core.text.TextSearchVisitor$1.run(TextSearchVisitor.java:148) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
The job has been introduced to fix bug 86963. I think to only way to solve both problems would be to invert the usage of the two threads, i.e. use the calling thread for progress notifications and do the actual search in the job.
- I don't think one is forced to serve a progress monitor in the same thread. At least this isn't specified by the progress monitor - In your case, why do you execute the search operation in the UI thread? That's something that should be avoided in general
> - I don't think one is forced to serve a progress monitor in the same thread. > At least this isn't specified by the progress monitor Hard to tell, the section "The workbench and threads" in http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/swt_threading.htm says that in general, Platform/UI APIs assume they're called in the UI thread unless noted otherwise. > - In your case, why do you execute the search operation in the UI thread? > That's something that should be avoided in general I'm investigating; I guess I can indeed set fork=true in my use case, which would solve this particular problem.
IProgressMonitor is org.eclipse.core.runtime. Operations are typically implemented in core which doesn't know of the concept of the UI thread. I think we could also file this against platform UI. They normally already have progress monitors that forward calls with sync exec.
> I think we could also file this against platform UI. They normally already have > progress monitors that forward calls with sync exec. Hm, they already do, but it's not possible in this case: In ModalContext.run(..), if fork is false, the operation must be run in the current thread (which is the UI thread in our case). If they would wrapper the progress monitor into an AccumulatingProgressMonitor, then updates would only occur in an asyncExec, which is only executed when the whole refactoring operation returns (i.e. progress bar is not redrawn at all...).
Just ran into the same issue with our product (based on Eclipse 3.7 / indigo). I was testing search-and-replace on files out of sync wrt the file system, with the new "Refresh on Access" Preference on.
*** Bug 451408 has been marked as a duplicate of this bug. ***
AERI led me here after it happened in Mars.1.
The error still occurs in 2020-03: eclipse.buildId=4.15.0.I20200305-0155 java.version=11.0.4 java.vendor=AdoptOpenJDK org.eclipse.core.jobs Error Mon Apr 20 17:35:19 CEST 2020 An internal error occurred during: "Search progress polling". org.eclipse.swt.SWTException: Invalid thread access at org.eclipse.swt.SWT.error(SWT.java:4723) at org.eclipse.swt.SWT.error(SWT.java:4638) at org.eclipse.swt.SWT.error(SWT.java:4609) at org.eclipse.swt.widgets.Widget.error(Widget.java:432) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:352) at org.eclipse.swt.widgets.Control.getForeground(Control.java:1366) at org.eclipse.jface.action.StatusLine.updateMessageLabel(StatusLine.java:681) at org.eclipse.jface.action.StatusLine.setMessage(StatusLine.java:559) at org.eclipse.jface.action.StatusLine.setMessage(StatusLine.java:545) at org.eclipse.jface.action.StatusLine.subTask(StatusLine.java:641) at org.eclipse.jface.action.StatusLineManager$1.subTask(StatusLineManager.java:192) at org.eclipse.core.runtime.SubMonitor$RootInfo.subTask(SubMonitor.java:255) at org.eclipse.core.runtime.SubMonitor.subTask(SubMonitor.java:667) at org.eclipse.core.runtime.ProgressMonitorWrapper.subTask(ProgressMonitorWrapper.java:168) at org.eclipse.core.runtime.SubProgressMonitor.subTask(SubProgressMonitor.java:197) at org.eclipse.core.runtime.ProgressMonitorWrapper.subTask(ProgressMonitorWrapper.java:168) at org.eclipse.core.runtime.SubProgressMonitor.subTask(SubProgressMonitor.java:197) at org.eclipse.core.runtime.ProgressMonitorWrapper.subTask(ProgressMonitorWrapper.java:168) at org.eclipse.core.runtime.SubProgressMonitor.subTask(SubProgressMonitor.java:197) at org.eclipse.search.internal.core.text.TextSearchVisitor$1.run(TextSearchVisitor.java:364) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
This has been finally solved for 4.16 *** This bug has been marked as a duplicate of bug 561416 ***
