Community
Participate
Working Groups
If the editor text is changed when the presenter thread is running, the presenter thread gets interrupted. This causes file/socket descriptors to be closed on unsuspecting code invoked by that thread.
Sorry but this is pretty generic. Please provide steps and more details. http://www.eclipse.org/eclipse/platform-text/development/bug-incomplete.htm
I thought my description made it pretty obvious what the problem is. To reproduce a specific instance of the problem: have an EFS provider that keeps its own metadata. Open a java editor with some NLSed strings. Place cursor over the externalized string, and at the same time type a character. If you did the above at the right time, the thread computing the hover will get interrupted, causing the currently read filedescriptor to be closed and corrupting the metadata kept by the EFS provider. java.nio.channels.ClosedByInterruptException at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:212) at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:663) at com.ibm.team.repository.common.internal.content.util.FileChannelUtil.readFully(FileChannelUtil.java:69) at com.ibm.team.repository.common.internal.content.util.BTreeHeap.readFully(BTreeHeap.java:185) at com.ibm.team.repository.common.internal.content.util.PersistentBTreeHeap.init(PersistentBTreeHeap.java:63) at com.ibm.team.repository.common.internal.content.util.PersistentBTreeHeap.<init>(PersistentBTreeHeap.java:36) at com.ibm.team.filesystem.client.internal.PersistentHeapManager$AutoClosingPersistentFileHeap.<init>(PersistentHeapManager.java:57) at com.ibm.team.filesystem.client.internal.PersistentHeapManager.getPersistentFileHeap(PersistentHeapManager.java:31) at com.ibm.team.filesystem.client.internal.Store.newPersistentBTreeHeap(Store.java:45) at com.ibm.team.repository.common.internal.content.util.PersistentDiskBackedHashMap.initFromFile(PersistentDiskBackedHashMap.java:80) at com.ibm.team.filesystem.client.internal.Store.<init>(Store.java:29) at com.ibm.team.filesystem.client.internal.SharingMetadata2$MetadataStore.<init>(SharingMetadata2.java:97) at com.ibm.team.filesystem.client.internal.SharingMetadata2$Directory.initEntries(SharingMetadata2.java:789) at com.ibm.team.filesystem.client.internal.LockableMap.init(LockableMap.java:38) at com.ibm.team.filesystem.client.internal.SharingMetadata2$Directory.init(SharingMetadata2.java:783) at com.ibm.team.filesystem.client.internal.SharingMetadata2$Directory.<init>(SharingMetadata2.java:778) at com.ibm.team.filesystem.client.internal.SharingMetadata2$MetadataDiskBackedMapManager.getLockableMap(SharingMetadata2.java:726) at com.ibm.team.filesystem.client.internal.DiskBackedMapManager.loadMap(DiskBackedMapManager.java:75) at com.ibm.team.filesystem.client.internal.SharingMetadata2.loadDirectory(SharingMetadata2.java:1235) at com.ibm.team.filesystem.client.internal.SharingMetadata2.getFileItemInfo(SharingMetadata2.java:1449) at com.ibm.team.filesystem.client.internal.MetadataChangeTracker.getFileItemInfo(MetadataChangeTracker.java:407) at com.ibm.team.filesystem.client.internal.copyfileareas.CopyFileAreaStore.getItemInfo(CopyFileAreaStore.java:1431) at com.ibm.team.filesystem.client.internal.ManagedFileStore.getVersionableHandle(ManagedFileStore.java:911) at com.ibm.team.filesystem.client.internal.ManagedFileStore.fetchInfoInternal(ManagedFileStore.java:370) at com.ibm.team.filesystem.client.internal.ManagedFileStore.fetchInfo(ManagedFileStore.java:347) at org.eclipse.core.filesystem.provider.FileStore.fetchInfo(FileStore.java:275) at org.eclipse.core.internal.localstore.FileSystemResourceManager.read(FileSystemResourceManager.java:601) at org.eclipse.core.internal.resources.File.getContents(File.java:287) at org.eclipse.core.internal.resources.File.getContents(File.java:276) at org.eclipse.jdt.internal.corext.refactoring.nls.NLSHintHelper.getProperties(NLSHintHelper.java:439) at org.eclipse.jdt.internal.ui.text.java.hover.NLSStringHover.getHoverInfo(NLSStringHover.java:116) at org.eclipse.jdt.internal.ui.text.java.hover.BestMatchHover.getHoverInfo(BestMatchHover.java:102) at org.eclipse.jdt.internal.ui.text.java.hover.JavaEditorTextHoverProxy.getHoverInfo(JavaEditorTextHoverProxy.java:69) at org.eclipse.jface.text.TextViewerHoverManager$4.run(TextViewerHoverManager.java:165)
It's by design that the hover thread gets interrupted and has been like that since day one. You need to protect your code against such situations, as they can happen with other threads as well.
Some fds cannot be reopened, either because they were passed in to the program (i.e. stdin, stdout, stderr) or because you may have interrupted a long running transaction and thus undone work that was done as part of some other invocation. You must not call Thread.interrupt() unless you really mean to have fds closed on code that is running. There is no way for the thread to protect itself against interruption, so unless you control the IO code you have no business calling Thread.interrupt().
> so unless you control the IO code you have no business >calling Thread.interrupt(). This is not spec'ed in JLS. Instead Thread.interrupt() clearly describes what happens and which exceptions are thrown. Even if we stop doing this that (or any other thread using your code) can be interrupted for many other reasons.
It is speced in the javadoc for Thread.interrupt() that it will close the fd. If that is not your intention then you should not be calling Thread.interrupt(). A thread cannot be interrupted for any other reason than somebody calling Thread.interrupt() on it. Consequently the person calling that method has to have the intention of closing fds.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
