Home » Eclipse Projects » Dynamic Languages Toolkit (DLTK) » Deadlock problem
| Deadlock problem [message #8137] |
Thu, 28 June 2007 07:59  |
 Mark Howe
Messages: 14
Registered: July 2009 |
Junior Member |
|
|
We are experiencing a deadlock when we call the search engine when the builder is running. For
instance if we create a new project and subsequently do a search for a type the ide deadlocks.
The problem is that the AutoBuildJob uses the MixinBuilder to create part of the index. But it uses
a DocumentAdapter which trys to sync on the UI thread. So if some other action is initiated from the
UI thread that requests a search, we get a deadlock when it hits the ReadWriteMonitor.
Look at SourceModule.getSourceAsCharArray() which causes DocumentAdapter.setContents() which causes
Display.syncExce();
1. Shouldn't builders avoid buffer usage or use a non-ui version?
2. Is it ok to call the search engine from the UI thread, if not what is the correct way?
3. Are you using the same pattern as JDT?
Thanks
Mark
(the two deadlocked threads)
Thread [Worker-0] (Suspended)
Object.wait(long) line: not available [native method]
Semaphore.acquire(long) line: 43
UISynchronizer.syncExec(Runnable) line: 136
Display.syncExec(Runnable) line: 4097
DocumentAdapter$DocumentSetCommand.set(String) line: 103
DocumentAdapter.setContents(String) line: 404
DocumentAdapter.setContents(char[]) line: 382
BuiltinSourceModule.openBuffer(IProgressMonitor, Object) line: 218
BuiltinSourceModule.buildStructure(OpenableElementInfo, IProgressMonitor, Map, IResource) line: 99
BuiltinSourceModule(Openable).generateInfos(Object, HashMap, IProgressMonitor) line: 182
BuiltinSourceModule(ModelElement).openWhenClosed(Object, IProgressMonitor) line: 166
BuiltinSourceModule(ModelElement).getElementInfo(IProgressMo nitor) line: 154
BuiltinSourceModule(ModelElement).getElementInfo() line: 139
BuiltinSourceModule(Openable).getBuffer() line: 212
BuiltinSourceModule.getSource() line: 246
MixinBuilder.loadContent(ISourceModule) line: 81
MixinBuilder.buildModelElements(IScriptProject, List, IProgressMonitor) line: 159
ScriptBuilder.buildElements(List, IProgressMonitor) line: 371
ScriptBuilder.fullBuild(IProgressMonitor) line: 259
ScriptBuilder.build(int, Map, IProgressMonitor) line: 159
BuildManager$2.run() line: 624
SafeRunner.run(ISafeRunnable) line: 37
BuildManager.basicBuild(int, IncrementalProjectBuilder, Map, MultiStatus, IProgressMonitor) line: 166
BuildManager.basicBuild(IProject, int, ICommand[], MultiStatus, IProgressMonitor) line: 197
BuildManager$1.run() line: 246
SafeRunner.run(ISafeRunnable) line: 37
BuildManager.basicBuild(IProject, int, MultiStatus, IProgressMonitor) line: 249
BuildManager.basicBuildLoop(IProject[], IProject[], int, MultiStatus, IProgressMonitor) line: 302
BuildManager.build(int, IProgressMonitor) line: 334
AutoBuildJob.doBuild(IProgressMonitor) line: 137
AutoBuildJob.run(IProgressMonitor) line: 235
Worker.run() line: 55
Thread [Worker-2] (Suspended)
Object.wait(long) line: not available [native method]
ReadWriteMonitor(Object).wait() line: 474
ReadWriteMonitor.enterRead() line: 30
PatternSearchJob.search(Index, IProgressMonitor) line: 146
PatternSearchJob.execute(IProgressMonitor) line: 77
IndexManager(JobManager).performConcurrentJob(IJob, int, IProgressMonitor) line: 263
BasicSearchEngine.searchAllTypeNames(char[], int, char[], int, int, IDLTKSearchScope,
IRestrictedAccessTypeRequestor, int, IProgressMonitor) line: 876
SearchEngine.searchAllTypeNames(char[], int, char[], int, int, IDLTKSearchScope,
TypeNameMatchRequestor, int,
IProgressMonitor) line: 484
called from UI thread
|
|
|
| Re: Deadlock problem [message #9748 is a reply to message #8137] |
Thu, 19 July 2007 13:23  |
Eclipse User |
|
|
|
Originally posted by: fourdman.xored.com
Hello,
I've investigated this problem. Problem source was really hard to find
and was in that it's not possible to use DocumentAdapter for built-in
source module's buffer. For standard source modules it's right, cause
their contents will be set during initialization, so there will not be
any need to call DocumentAdapter.setContents from non-ui thread. For
built-in modules it is no so, because DocumentAdapter by it's design
doesn't allow to set it's content not in ui thread without locking.
By now I've changed DocumentAdapter to Buffer for built-in modules. It
seems that it resolves a bug. But frankly speaking I'm not sure that it
is a fully correct&beautiful solution, so I'd like to work more on it a
bit later. By now you can update from cvs HEAD and get the changes.
Mark Howe wrote:
> We are experiencing a deadlock when we call the search engine when the
> builder is running. For instance if we create a new project and
> subsequently do a search for a type the ide deadlocks.
>
> The problem is that the AutoBuildJob uses the MixinBuilder to create
> part of the index. But it uses a DocumentAdapter which trys to sync on
> the UI thread. So if some other action is initiated from the UI thread
> that requests a search, we get a deadlock when it hits the
> ReadWriteMonitor.
>
> Look at SourceModule.getSourceAsCharArray() which causes
> DocumentAdapter.setContents() which causes Display.syncExce();
>
> 1. Shouldn't builders avoid buffer usage or use a non-ui version?
> 2. Is it ok to call the search engine from the UI thread, if not what is
> the correct way?
> 3. Are you using the same pattern as JDT?
>
> Thanks
> Mark
> (the two deadlocked threads)
>
> Thread [Worker-0] (Suspended)
> Object.wait(long) line: not available [native method]
> Semaphore.acquire(long) line: 43
> UISynchronizer.syncExec(Runnable) line: 136
> Display.syncExec(Runnable) line: 4097
> DocumentAdapter$DocumentSetCommand.set(String) line: 103
> DocumentAdapter.setContents(String) line: 404
> DocumentAdapter.setContents(char[]) line: 382
> BuiltinSourceModule.openBuffer(IProgressMonitor, Object) line: 218
> BuiltinSourceModule.buildStructure(OpenableElementInfo,
> IProgressMonitor, Map, IResource) line: 99
> BuiltinSourceModule(Openable).generateInfos(Object, HashMap,
> IProgressMonitor) line: 182
> BuiltinSourceModule(ModelElement).openWhenClosed(Object,
> IProgressMonitor) line: 166
> BuiltinSourceModule(ModelElement).getElementInfo(IProgressMo nitor)
> line: 154
> BuiltinSourceModule(ModelElement).getElementInfo() line: 139
> BuiltinSourceModule(Openable).getBuffer() line: 212
> BuiltinSourceModule.getSource() line: 246
> MixinBuilder.loadContent(ISourceModule) line: 81
> MixinBuilder.buildModelElements(IScriptProject, List,
> IProgressMonitor) line: 159
> ScriptBuilder.buildElements(List, IProgressMonitor) line: 371
> ScriptBuilder.fullBuild(IProgressMonitor) line: 259
> ScriptBuilder.build(int, Map, IProgressMonitor) line: 159
> BuildManager$2.run() line: 624
> SafeRunner.run(ISafeRunnable) line: 37
> BuildManager.basicBuild(int, IncrementalProjectBuilder, Map,
> MultiStatus, IProgressMonitor) line: 166
> BuildManager.basicBuild(IProject, int, ICommand[], MultiStatus,
> IProgressMonitor) line: 197
> BuildManager$1.run() line: 246
> SafeRunner.run(ISafeRunnable) line: 37
> BuildManager.basicBuild(IProject, int, MultiStatus,
> IProgressMonitor) line: 249
> BuildManager.basicBuildLoop(IProject[], IProject[], int,
> MultiStatus, IProgressMonitor) line: 302
> BuildManager.build(int, IProgressMonitor) line: 334
> AutoBuildJob.doBuild(IProgressMonitor) line: 137
> AutoBuildJob.run(IProgressMonitor) line: 235
> Worker.run() line: 55
>
>
>
> Thread [Worker-2] (Suspended)
> Object.wait(long) line: not available [native method]
> ReadWriteMonitor(Object).wait() line: 474
> ReadWriteMonitor.enterRead() line: 30
> PatternSearchJob.search(Index, IProgressMonitor) line: 146
> PatternSearchJob.execute(IProgressMonitor) line: 77
> IndexManager(JobManager).performConcurrentJob(IJob, int,
> IProgressMonitor) line: 263
> BasicSearchEngine.searchAllTypeNames(char[], int, char[], int, int,
> IDLTKSearchScope,
>
> IRestrictedAccessTypeRequestor, int, IProgressMonitor) line: 876
> SearchEngine.searchAllTypeNames(char[], int, char[], int, int,
> IDLTKSearchScope, TypeNameMatchRequestor, int,
>
> IProgressMonitor) line: 484
> called from UI thread
|
|
|
| Re: Deadlock problem [message #9837 is a reply to message #9748] |
Thu, 19 July 2007 19:27 |
Shelby Sanders
Messages: 13
Registered: July 2009 |
Junior Member |
|
|
Yes, we had discovered the same issue.
We put a hack in place which avoids using any Buffer during execution of
MixinBuilder, and that seems to work. However, we are hoping there is a
better solution to the overall problem, since this can happen in other
instances as well.
> Hello,
>
> I've investigated this problem. Problem source was really hard to find
> and was in that it's not possible to use DocumentAdapter for built-in
> source module's buffer. For standard source modules it's right, cause
> their contents will be set during initialization, so there will not be
> any need to call DocumentAdapter.setContents from non-ui thread. For
> built-in modules it is no so, because DocumentAdapter by it's design
> doesn't allow to set it's content not in ui thread without locking.
>
> By now I've changed DocumentAdapter to Buffer for built-in modules. It
> seems that it resolves a bug. But frankly speaking I'm not sure that it
> is a fully correct&beautiful solution, so I'd like to work more on it a
> bit later. By now you can update from cvs HEAD and get the changes.
>
>
> Mark Howe wrote:
>> We are experiencing a deadlock when we call the search engine when the
>> builder is running. For instance if we create a new project and
>> subsequently do a search for a type the ide deadlocks.
>>
>> The problem is that the AutoBuildJob uses the MixinBuilder to create
>> part of the index. But it uses a DocumentAdapter which trys to sync on
>> the UI thread. So if some other action is initiated from the UI thread
>> that requests a search, we get a deadlock when it hits the
>> ReadWriteMonitor.
>>
>> Look at SourceModule.getSourceAsCharArray() which causes
>> DocumentAdapter.setContents() which causes Display.syncExce();
>>
>> 1. Shouldn't builders avoid buffer usage or use a non-ui version?
>> 2. Is it ok to call the search engine from the UI thread, if not what is
>> the correct way?
>> 3. Are you using the same pattern as JDT?
>>
>> Thanks
>> Mark
>> (the two deadlocked threads)
>>
>> Thread [Worker-0] (Suspended)
>> Object.wait(long) line: not available [native method]
>> Semaphore.acquire(long) line: 43
>> UISynchronizer.syncExec(Runnable) line: 136
>> Display.syncExec(Runnable) line: 4097
>> DocumentAdapter$DocumentSetCommand.set(String) line: 103
>> DocumentAdapter.setContents(String) line: 404
>> DocumentAdapter.setContents(char[]) line: 382
>> BuiltinSourceModule.openBuffer(IProgressMonitor, Object) line: 218
>> BuiltinSourceModule.buildStructure(OpenableElementInfo,
>> IProgressMonitor, Map, IResource) line: 99
>> BuiltinSourceModule(Openable).generateInfos(Object, HashMap,
>> IProgressMonitor) line: 182
>> BuiltinSourceModule(ModelElement).openWhenClosed(Object,
>> IProgressMonitor) line: 166
>> BuiltinSourceModule(ModelElement).getElementInfo(IProgressMo nitor)
>> line: 154
>> BuiltinSourceModule(ModelElement).getElementInfo() line: 139
>> BuiltinSourceModule(Openable).getBuffer() line: 212
>> BuiltinSourceModule.getSource() line: 246
>> MixinBuilder.loadContent(ISourceModule) line: 81
>> MixinBuilder.buildModelElements(IScriptProject, List,
>> IProgressMonitor) line: 159
>> ScriptBuilder.buildElements(List, IProgressMonitor) line: 371
>> ScriptBuilder.fullBuild(IProgressMonitor) line: 259
>> ScriptBuilder.build(int, Map, IProgressMonitor) line: 159
>> BuildManager$2.run() line: 624
>> SafeRunner.run(ISafeRunnable) line: 37
>> BuildManager.basicBuild(int, IncrementalProjectBuilder, Map,
>> MultiStatus, IProgressMonitor) line: 166
>> BuildManager.basicBuild(IProject, int, ICommand[], MultiStatus,
>> IProgressMonitor) line: 197
>> BuildManager$1.run() line: 246
>> SafeRunner.run(ISafeRunnable) line: 37
>> BuildManager.basicBuild(IProject, int, MultiStatus,
>> IProgressMonitor) line: 249
>> BuildManager.basicBuildLoop(IProject[], IProject[], int,
>> MultiStatus, IProgressMonitor) line: 302
>> BuildManager.build(int, IProgressMonitor) line: 334
>> AutoBuildJob.doBuild(IProgressMonitor) line: 137
>> AutoBuildJob.run(IProgressMonitor) line: 235
>> Worker.run() line: 55
>>
>>
>>
>> Thread [Worker-2] (Suspended)
>> Object.wait(long) line: not available [native method]
>> ReadWriteMonitor(Object).wait() line: 474
>> ReadWriteMonitor.enterRead() line: 30
>> PatternSearchJob.search(Index, IProgressMonitor) line: 146
>> PatternSearchJob.execute(IProgressMonitor) line: 77
>> IndexManager(JobManager).performConcurrentJob(IJob, int,
>> IProgressMonitor) line: 263
>> BasicSearchEngine.searchAllTypeNames(char[], int, char[], int, int,
>> IDLTKSearchScope,
>>
>> IRestrictedAccessTypeRequestor, int, IProgressMonitor) line: 876
>> SearchEngine.searchAllTypeNames(char[], int, char[], int, int,
>> IDLTKSearchScope, TypeNameMatchRequestor, int,
>>
>> IProgressMonitor) line: 484
>> called from UI thread
Thank You,
Shelby Sanders
|
|
|
| Re: Deadlock problem [message #13192 is a reply to message #9748] |
Wed, 15 August 2007 22:07 |
Shelby Sanders
Messages: 13
Registered: July 2009 |
Junior Member |
|
|
Is there any further status on this issue?
We have actually run into it in other cases now. The general idea being
that if the UI thread and any non-UI thread call RubyMixinModel.create**()
at the same time, there is a deadlock.
The latest case is if you invoke code completion in the editor while your
mouse cursor is hovering. RubyCompletionEngine.completeClassMethods() is
called on the UI thread and AbstractScriptEditorTextHover.getHoverInfo() is
called in a worker thread.
Thank You,
Shelby Sanders
> Hello,
>
> I've investigated this problem. Problem source was really hard to find
> and was in that it's not possible to use DocumentAdapter for built-in
> source module's buffer. For standard source modules it's right, cause
> their contents will be set during initialization, so there will not be
> any need to call DocumentAdapter.setContents from non-ui thread. For
> built-in modules it is no so, because DocumentAdapter by it's design
> doesn't allow to set it's content not in ui thread without locking.
>
> By now I've changed DocumentAdapter to Buffer for built-in modules. It
> seems that it resolves a bug. But frankly speaking I'm not sure that it
> is a fully correct&beautiful solution, so I'd like to work more on it a
> bit later. By now you can update from cvs HEAD and get the changes.
>
>
> Mark Howe wrote:
>> We are experiencing a deadlock when we call the search engine when the
>> builder is running. For instance if we create a new project and
>> subsequently do a search for a type the ide deadlocks.
>>
>> The problem is that the AutoBuildJob uses the MixinBuilder to create
>> part of the index. But it uses a DocumentAdapter which trys to sync on
>> the UI thread. So if some other action is initiated from the UI thread
>> that requests a search, we get a deadlock when it hits the
>> ReadWriteMonitor.
>>
>> Look at SourceModule.getSourceAsCharArray() which causes
>> DocumentAdapter.setContents() which causes Display.syncExce();
>>
>> 1. Shouldn't builders avoid buffer usage or use a non-ui version?
>> 2. Is it ok to call the search engine from the UI thread, if not what is
>> the correct way?
>> 3. Are you using the same pattern as JDT?
>>
>> Thanks
>> Mark
>> (the two deadlocked threads)
>>
>> Thread [Worker-0] (Suspended)
>> Object.wait(long) line: not available [native method]
>> Semaphore.acquire(long) line: 43
>> UISynchronizer.syncExec(Runnable) line: 136
>> Display.syncExec(Runnable) line: 4097
>> DocumentAdapter$DocumentSetCommand.set(String) line: 103
>> DocumentAdapter.setContents(String) line: 404
>> DocumentAdapter.setContents(char[]) line: 382
>> BuiltinSourceModule.openBuffer(IProgressMonitor, Object) line: 218
>> BuiltinSourceModule.buildStructure(OpenableElementInfo,
>> IProgressMonitor, Map, IResource) line: 99
>> BuiltinSourceModule(Openable).generateInfos(Object, HashMap,
>> IProgressMonitor) line: 182
>> BuiltinSourceModule(ModelElement).openWhenClosed(Object,
>> IProgressMonitor) line: 166
>> BuiltinSourceModule(ModelElement).getElementInfo(IProgressMo nitor)
>> line: 154
>> BuiltinSourceModule(ModelElement).getElementInfo() line: 139
>> BuiltinSourceModule(Openable).getBuffer() line: 212
>> BuiltinSourceModule.getSource() line: 246
>> MixinBuilder.loadContent(ISourceModule) line: 81
>> MixinBuilder.buildModelElements(IScriptProject, List,
>> IProgressMonitor) line: 159
>> ScriptBuilder.buildElements(List, IProgressMonitor) line: 371
>> ScriptBuilder.fullBuild(IProgressMonitor) line: 259
>> ScriptBuilder.build(int, Map, IProgressMonitor) line: 159
>> BuildManager$2.run() line: 624
>> SafeRunner.run(ISafeRunnable) line: 37
>> BuildManager.basicBuild(int, IncrementalProjectBuilder, Map,
>> MultiStatus, IProgressMonitor) line: 166
>> BuildManager.basicBuild(IProject, int, ICommand[], MultiStatus,
>> IProgressMonitor) line: 197
>> BuildManager$1.run() line: 246
>> SafeRunner.run(ISafeRunnable) line: 37
>> BuildManager.basicBuild(IProject, int, MultiStatus,
>> IProgressMonitor) line: 249
>> BuildManager.basicBuildLoop(IProject[], IProject[], int,
>> MultiStatus, IProgressMonitor) line: 302
>> BuildManager.build(int, IProgressMonitor) line: 334
>> AutoBuildJob.doBuild(IProgressMonitor) line: 137
>> AutoBuildJob.run(IProgressMonitor) line: 235
>> Worker.run() line: 55
>>
>>
>>
>> Thread [Worker-2] (Suspended)
>> Object.wait(long) line: not available [native method]
>> ReadWriteMonitor(Object).wait() line: 474
>> ReadWriteMonitor.enterRead() line: 30
>> PatternSearchJob.search(Index, IProgressMonitor) line: 146
>> PatternSearchJob.execute(IProgressMonitor) line: 77
>> IndexManager(JobManager).performConcurrentJob(IJob, int,
>> IProgressMonitor) line: 263
>> BasicSearchEngine.searchAllTypeNames(char[], int, char[], int, int,
>> IDLTKSearchScope,
>>
>> IRestrictedAccessTypeRequestor, int, IProgressMonitor) line: 876
>> SearchEngine.searchAllTypeNames(char[], int, char[], int, int,
>> IDLTKSearchScope, TypeNameMatchRequestor, int,
>>
>> IProgressMonitor) line: 484
>> called from UI thread
|
|
|
| Re: Deadlock problem [message #13249 is a reply to message #13192] |
Thu, 16 August 2007 11:55 |
Andrei Sobolev
Messages: 72
Registered: July 2009 |
Member |
|
|
Hi Shelby,
Mikhail already fixed bug with Builtin elements.
Actually We could not reproduce this bug. We tried to reproduce as you
mentioned but it also works.
Could you provide script on which it is happend?
Thanks,
Andrei.
> Is there any further status on this issue?
>
> We have actually run into it in other cases now. The general idea being
> that if the UI thread and any non-UI thread call RubyMixinModel.create**()
> at the same time, there is a deadlock.
>
> The latest case is if you invoke code completion in the editor while your
> mouse cursor is hovering. RubyCompletionEngine.completeClassMethods() is
> called on the UI thread and AbstractScriptEditorTextHover.getHoverInfo() is
> called in a worker thread.
>
> Thank You,
> Shelby Sanders
>
>> Hello,
>>
>> I've investigated this problem. Problem source was really hard to find
>> and was in that it's not possible to use DocumentAdapter for built-in
>> source module's buffer. For standard source modules it's right, cause
>> their contents will be set during initialization, so there will not be
>> any need to call DocumentAdapter.setContents from non-ui thread. For
>> built-in modules it is no so, because DocumentAdapter by it's design
>> doesn't allow to set it's content not in ui thread without locking.
>>
>> By now I've changed DocumentAdapter to Buffer for built-in modules. It
>> seems that it resolves a bug. But frankly speaking I'm not sure that it
>> is a fully correct&beautiful solution, so I'd like to work more on it a
>> bit later. By now you can update from cvs HEAD and get the changes.
>>
>>
>> Mark Howe wrote:
>>> We are experiencing a deadlock when we call the search engine when the
>>> builder is running. For instance if we create a new project and
>>> subsequently do a search for a type the ide deadlocks.
>>>
>>> The problem is that the AutoBuildJob uses the MixinBuilder to create
>>> part of the index. But it uses a DocumentAdapter which trys to sync on
>>> the UI thread. So if some other action is initiated from the UI thread
>>> that requests a search, we get a deadlock when it hits the
>>> ReadWriteMonitor.
>>>
>>> Look at SourceModule.getSourceAsCharArray() which causes
>>> DocumentAdapter.setContents() which causes Display.syncExce();
>>>
>>> 1. Shouldn't builders avoid buffer usage or use a non-ui version?
>>> 2. Is it ok to call the search engine from the UI thread, if not what is
>>> the correct way?
>>> 3. Are you using the same pattern as JDT?
>>>
>>> Thanks
>>> Mark
>>> (the two deadlocked threads)
>>>
>>> Thread [Worker-0] (Suspended)
>>> Object.wait(long) line: not available [native method]
>>> Semaphore.acquire(long) line: 43
>>> UISynchronizer.syncExec(Runnable) line: 136
>>> Display.syncExec(Runnable) line: 4097
>>> DocumentAdapter$DocumentSetCommand.set(String) line: 103
>>> DocumentAdapter.setContents(String) line: 404
>>> DocumentAdapter.setContents(char[]) line: 382
>>> BuiltinSourceModule.openBuffer(IProgressMonitor, Object) line: 218
>>> BuiltinSourceModule.buildStructure(OpenableElementInfo,
>>> IProgressMonitor, Map, IResource) line: 99
>>> BuiltinSourceModule(Openable).generateInfos(Object, HashMap,
>>> IProgressMonitor) line: 182
>>> BuiltinSourceModule(ModelElement).openWhenClosed(Object,
>>> IProgressMonitor) line: 166
>>> BuiltinSourceModule(ModelElement).getElementInfo(IProgressMo nitor)
>>> line: 154
>>> BuiltinSourceModule(ModelElement).getElementInfo() line: 139
>>> BuiltinSourceModule(Openable).getBuffer() line: 212
>>> BuiltinSourceModule.getSource() line: 246
>>> MixinBuilder.loadContent(ISourceModule) line: 81
>>> MixinBuilder.buildModelElements(IScriptProject, List,
>>> IProgressMonitor) line: 159
>>> ScriptBuilder.buildElements(List, IProgressMonitor) line: 371
>>> ScriptBuilder.fullBuild(IProgressMonitor) line: 259
>>> ScriptBuilder.build(int, Map, IProgressMonitor) line: 159
>>> BuildManager$2.run() line: 624
>>> SafeRunner.run(ISafeRunnable) line: 37
>>> BuildManager.basicBuild(int, IncrementalProjectBuilder, Map,
>>> MultiStatus, IProgressMonitor) line: 166
>>> BuildManager.basicBuild(IProject, int, ICommand[], MultiStatus,
>>> IProgressMonitor) line: 197
>>> BuildManager$1.run() line: 246
>>> SafeRunner.run(ISafeRunnable) line: 37
>>> BuildManager.basicBuild(IProject, int, MultiStatus,
>>> IProgressMonitor) line: 249
>>> BuildManager.basicBuildLoop(IProject[], IProject[], int,
>>> MultiStatus, IProgressMonitor) line: 302
>>> BuildManager.build(int, IProgressMonitor) line: 334
>>> AutoBuildJob.doBuild(IProgressMonitor) line: 137
>>> AutoBuildJob.run(IProgressMonitor) line: 235
>>> Worker.run() line: 55
>>>
>>>
>>>
>>> Thread [Worker-2] (Suspended)
>>> Object.wait(long) line: not available [native method]
>>> ReadWriteMonitor(Object).wait() line: 474
>>> ReadWriteMonitor.enterRead() line: 30
>>> PatternSearchJob.search(Index, IProgressMonitor) line: 146
>>> PatternSearchJob.execute(IProgressMonitor) line: 77
>>> IndexManager(JobManager).performConcurrentJob(IJob, int,
>>> IProgressMonitor) line: 263
>>> BasicSearchEngine.searchAllTypeNames(char[], int, char[], int, int,
>>> IDLTKSearchScope,
>>>
>>> IRestrictedAccessTypeRequestor, int, IProgressMonitor) line: 876
>>> SearchEngine.searchAllTypeNames(char[], int, char[], int, int,
>>> IDLTKSearchScope, TypeNameMatchRequestor, int,
>>>
>>> IProgressMonitor) line: 484
>>> called from UI thread
>
|
|
|
| Re: Deadlock problem [message #13333 is a reply to message #13249] |
Thu, 16 August 2007 19:08 |
Shelby Sanders
Messages: 13
Registered: July 2009 |
Junior Member |
|
|
Andrei,
Can you provide details about what changes where made and the associated
revisions? As far as I know, we are pretty close to the CVS HEAD, but maybe
we missed something.
It doesn't seem to be connected to any specific script or class. However,
the next time it happens I'll look at which files are being read in order to
confirm whether or not it is in a built-in.
Thank You,
Shelby Sanders
> Hi Shelby,
>
> Mikhail already fixed bug with Builtin elements.
>
> Actually We could not reproduce this bug. We tried to reproduce as you
> mentioned but it also works.
>
> Could you provide script on which it is happend?
>
> Thanks,
> Andrei.
>
>> Is there any further status on this issue?
>>
>> We have actually run into it in other cases now. The general idea being
>> that if the UI thread and any non-UI thread call RubyMixinModel.create**()
>> at the same time, there is a deadlock.
>>
>> The latest case is if you invoke code completion in the editor while your
>> mouse cursor is hovering. RubyCompletionEngine.completeClassMethods() is
>> called on the UI thread and AbstractScriptEditorTextHover.getHoverInfo() is
>> called in a worker thread.
>>
>> Thank You,
>> Shelby Sanders
>>
>>> Hello,
>>>
>>> I've investigated this problem. Problem source was really hard to find
>>> and was in that it's not possible to use DocumentAdapter for built-in
>>> source module's buffer. For standard source modules it's right, cause
>>> their contents will be set during initialization, so there will not be
>>> any need to call DocumentAdapter.setContents from non-ui thread. For
>>> built-in modules it is no so, because DocumentAdapter by it's design
>>> doesn't allow to set it's content not in ui thread without locking.
>>>
>>> By now I've changed DocumentAdapter to Buffer for built-in modules. It
>>> seems that it resolves a bug. But frankly speaking I'm not sure that it
>>> is a fully correct&beautiful solution, so I'd like to work more on it a
>>> bit later. By now you can update from cvs HEAD and get the changes.
>>>
>>>
>>> Mark Howe wrote:
>>>> We are experiencing a deadlock when we call the search engine when the
>>>> builder is running. For instance if we create a new project and
>>>> subsequently do a search for a type the ide deadlocks.
>>>>
>>>> The problem is that the AutoBuildJob uses the MixinBuilder to create
>>>> part of the index. But it uses a DocumentAdapter which trys to sync on
>>>> the UI thread. So if some other action is initiated from the UI thread
>>>> that requests a search, we get a deadlock when it hits the
>>>> ReadWriteMonitor.
>>>>
>>>> Look at SourceModule.getSourceAsCharArray() which causes
>>>> DocumentAdapter.setContents() which causes Display.syncExce();
>>>>
>>>> 1. Shouldn't builders avoid buffer usage or use a non-ui version?
>>>> 2. Is it ok to call the search engine from the UI thread, if not what is
>>>> the correct way?
>>>> 3. Are you using the same pattern as JDT?
>>>>
>>>> Thanks
>>>> Mark
>>>> (the two deadlocked threads)
>>>>
>>>> Thread [Worker-0] (Suspended)
>>>> Object.wait(long) line: not available [native method]
>>>> Semaphore.acquire(long) line: 43
>>>> UISynchronizer.syncExec(Runnable) line: 136
>>>> Display.syncExec(Runnable) line: 4097
>>>> DocumentAdapter$DocumentSetCommand.set(String) line: 103
>>>> DocumentAdapter.setContents(String) line: 404
>>>> DocumentAdapter.setContents(char[]) line: 382
>>>> BuiltinSourceModule.openBuffer(IProgressMonitor, Object) line: 218
>>>> BuiltinSourceModule.buildStructure(OpenableElementInfo,
>>>> IProgressMonitor, Map, IResource) line: 99
>>>> BuiltinSourceModule(Openable).generateInfos(Object, HashMap,
>>>> IProgressMonitor) line: 182
>>>> BuiltinSourceModule(ModelElement).openWhenClosed(Object,
>>>> IProgressMonitor) line: 166
>>>> BuiltinSourceModule(ModelElement).getElementInfo(IProgressMo nitor)
>>>> line: 154
>>>> BuiltinSourceModule(ModelElement).getElementInfo() line: 139
>>>> BuiltinSourceModule(Openable).getBuffer() line: 212
>>>> BuiltinSourceModule.getSource() line: 246
>>>> MixinBuilder.loadContent(ISourceModule) line: 81
>>>> MixinBuilder.buildModelElements(IScriptProject, List,
>>>> IProgressMonitor) line: 159
>>>> ScriptBuilder.buildElements(List, IProgressMonitor) line: 371
>>>> ScriptBuilder.fullBuild(IProgressMonitor) line: 259
>>>> ScriptBuilder.build(int, Map, IProgressMonitor) line: 159
>>>> BuildManager$2.run() line: 624
>>>> SafeRunner.run(ISafeRunnable) line: 37
>>>> BuildManager.basicBuild(int, IncrementalProjectBuilder, Map,
>>>> MultiStatus, IProgressMonitor) line: 166
>>>> BuildManager.basicBuild(IProject, int, ICommand[], MultiStatus,
>>>> IProgressMonitor) line: 197
>>>> BuildManager$1.run() line: 246
>>>> SafeRunner.run(ISafeRunnable) line: 37
>>>> BuildManager.basicBuild(IProject, int, MultiStatus,
>>>> IProgressMonitor) line: 249
>>>> BuildManager.basicBuildLoop(IProject[], IProject[], int,
>>>> MultiStatus, IProgressMonitor) line: 302
>>>> BuildManager.build(int, IProgressMonitor) line: 334
>>>> AutoBuildJob.doBuild(IProgressMonitor) line: 137
>>>> AutoBuildJob.run(IProgressMonitor) line: 235
>>>> Worker.run() line: 55
>>>>
>>>>
>>>>
>>>> Thread [Worker-2] (Suspended)
>>>> Object.wait(long) line: not available [native method]
>>>> ReadWriteMonitor(Object).wait() line: 474
>>>> ReadWriteMonitor.enterRead() line: 30
>>>> PatternSearchJob.search(Index, IProgressMonitor) line: 146
>>>> PatternSearchJob.execute(IProgressMonitor) line: 77
>>>> IndexManager(JobManager).performConcurrentJob(IJob, int,
>>>> IProgressMonitor) line: 263
>>>> BasicSearchEngine.searchAllTypeNames(char[], int, char[], int, int,
>>>> IDLTKSearchScope,
>>>>
>>>> IRestrictedAccessTypeRequestor, int, IProgressMonitor) line: 876
>>>> SearchEngine.searchAllTypeNames(char[], int, char[], int, int,
>>>> IDLTKSearchScope, TypeNameMatchRequestor, int,
>>>>
>>>> IProgressMonitor) line: 484
>>>> called from UI thread
|
|
|
| Re: Deadlock problem [message #13375 is a reply to message #13333] |
Fri, 17 August 2007 07:36 |
Andrei Sobolev
Messages: 72
Registered: July 2009 |
Member |
|
|
Hi Shelby,
> Can you provide details about what changes where made and the associated
> revisions? As far as I know, we are pretty close to the CVS HEAD, but maybe
> we missed something.
You should have revision 1.4 of class DocumentAdapter
(org.eclipse.dltk.internal.ui.editor package).
If it is correct, then all try to rewrite built element logic.
Andrei.
>
> It doesn't seem to be connected to any specific script or class. However,
> the next time it happens I'll look at which files are being read in order to
> confirm whether or not it is in a built-in.
>
> Thank You,
> Shelby Sanders
>
>> Hi Shelby,
>>
>> Mikhail already fixed bug with Builtin elements.
>>
>> Actually We could not reproduce this bug. We tried to reproduce as you
>> mentioned but it also works.
>>
>> Could you provide script on which it is happend?
>>
>> Thanks,
>> Andrei.
>>
>>> Is there any further status on this issue?
>>>
>>> We have actually run into it in other cases now. The general idea being
>>> that if the UI thread and any non-UI thread call RubyMixinModel.create**()
>>> at the same time, there is a deadlock.
>>>
>>> The latest case is if you invoke code completion in the editor while your
>>> mouse cursor is hovering. RubyCompletionEngine.completeClassMethods() is
>>> called on the UI thread and AbstractScriptEditorTextHover.getHoverInfo() is
>>> called in a worker thread.
>>>
>>> Thank You,
>>> Shelby Sanders
>>>
>>>> Hello,
>>>>
>>>> I've investigated this problem. Problem source was really hard to find
>>>> and was in that it's not possible to use DocumentAdapter for built-in
>>>> source module's buffer. For standard source modules it's right, cause
>>>> their contents will be set during initialization, so there will not be
>>>> any need to call DocumentAdapter.setContents from non-ui thread. For
>>>> built-in modules it is no so, because DocumentAdapter by it's design
>>>> doesn't allow to set it's content not in ui thread without locking.
>>>>
>>>> By now I've changed DocumentAdapter to Buffer for built-in modules. It
>>>> seems that it resolves a bug. But frankly speaking I'm not sure that it
>>>> is a fully correct&beautiful solution, so I'd like to work more on it a
>>>> bit later. By now you can update from cvs HEAD and get the changes.
>>>>
>>>>
>>>> Mark Howe wrote:
>>>>> We are experiencing a deadlock when we call the search engine when the
>>>>> builder is running. For instance if we create a new project and
>>>>> subsequently do a search for a type the ide deadlocks.
>>>>>
>>>>> The problem is that the AutoBuildJob uses the MixinBuilder to create
>>>>> part of the index. But it uses a DocumentAdapter which trys to sync on
>>>>> the UI thread. So if some other action is initiated from the UI thread
>>>>> that requests a search, we get a deadlock when it hits the
>>>>> ReadWriteMonitor.
>>>>>
>>>>> Look at SourceModule.getSourceAsCharArray() which causes
>>>>> DocumentAdapter.setContents() which causes Display.syncExce();
>>>>>
>>>>> 1. Shouldn't builders avoid buffer usage or use a non-ui version?
>>>>> 2. Is it ok to call the search engine from the UI thread, if not what is
>>>>> the correct way?
>>>>> 3. Are you using the same pattern as JDT?
>>>>>
>>>>> Thanks
>>>>> Mark
>>>>> (the two deadlocked threads)
>>>>>
>>>>> Thread [Worker-0] (Suspended)
>>>>> Object.wait(long) line: not available [native method]
>>>>> Semaphore.acquire(long) line: 43
>>>>> UISynchronizer.syncExec(Runnable) line: 136
>>>>> Display.syncExec(Runnable) line: 4097
>>>>> DocumentAdapter$DocumentSetCommand.set(String) line: 103
>>>>> DocumentAdapter.setContents(String) line: 404
>>>>> DocumentAdapter.setContents(char[]) line: 382
>>>>> BuiltinSourceModule.openBuffer(IProgressMonitor, Object) line: 218
>>>>> BuiltinSourceModule.buildStructure(OpenableElementInfo,
>>>>> IProgressMonitor, Map, IResource) line: 99
>>>>> BuiltinSourceModule(Openable).generateInfos(Object, HashMap,
>>>>> IProgressMonitor) line: 182
>>>>> BuiltinSourceModule(ModelElement).openWhenClosed(Object,
>>>>> IProgressMonitor) line: 166
>>>>> BuiltinSourceModule(ModelElement).getElementInfo(IProgressMo nitor)
>>>>> line: 154
>>>>> BuiltinSourceModule(ModelElement).getElementInfo() line: 139
>>>>> BuiltinSourceModule(Openable).getBuffer() line: 212
>>>>> BuiltinSourceModule.getSource() line: 246
>>>>> MixinBuilder.loadContent(ISourceModule) line: 81
>>>>> MixinBuilder.buildModelElements(IScriptProject, List,
>>>>> IProgressMonitor) line: 159
>>>>> ScriptBuilder.buildElements(List, IProgressMonitor) line: 371
>>>>> ScriptBuilder.fullBuild(IProgressMonitor) line: 259
>>>>> ScriptBuilder.build(int, Map, IProgressMonitor) line: 159
>>>>> BuildManager$2.run() line: 624
>>>>> SafeRunner.run(ISafeRunnable) line: 37
>>>>> BuildManager.basicBuild(int, IncrementalProjectBuilder, Map,
>>>>> MultiStatus, IProgressMonitor) line: 166
>>>>> BuildManager.basicBuild(IProject, int, ICommand[], MultiStatus,
>>>>> IProgressMonitor) line: 197
>>>>> BuildManager$1.run() line: 246
>>>>> SafeRunner.run(ISafeRunnable) line: 37
>>>>> BuildManager.basicBuild(IProject, int, MultiStatus,
>>>>> IProgressMonitor) line: 249
>>>>> BuildManager.basicBuildLoop(IProject[], IProject[], int,
>>>>> MultiStatus, IProgressMonitor) line: 302
>>>>> BuildManager.build(int, IProgressMonitor) line: 334
>>>>> AutoBuildJob.doBuild(IProgressMonitor) line: 137
>>>>> AutoBuildJob.run(IProgressMonitor) line: 235
>>>>> Worker.run() line: 55
>>>>>
>>>>>
>>>>>
>>>>> Thread [Worker-2] (Suspended)
>>>>> Object.wait(long) line: not available [native method]
>>>>> ReadWriteMonitor(Object).wait() line: 474
>>>>> ReadWriteMonitor.enterRead() line: 30
>>>>> PatternSearchJob.search(Index, IProgressMonitor) line: 146
>>>>> PatternSearchJob.execute(IProgressMonitor) line: 77
>>>>> IndexManager(JobManager).performConcurrentJob(IJob, int,
>>>>> IProgressMonitor) line: 263
>>>>> BasicSearchEngine.searchAllTypeNames(char[], int, char[], int, int,
>>>>> IDLTKSearchScope,
>>>>>
>>>>> IRestrictedAccessTypeRequestor, int, IProgressMonitor) line: 876
>>>>> SearchEngine.searchAllTypeNames(char[], int, char[], int, int,
>>>>> IDLTKSearchScope, TypeNameMatchRequestor, int,
>>>>>
>>>>> IProgressMonitor) line: 484
>>>>> called from UI thread
>
|
|
|
| Re: Deadlock problem [message #14604 is a reply to message #13375] |
Tue, 21 August 2007 05:12 |
Shelby Sanders
Messages: 13
Registered: July 2009 |
Junior Member |
|
|
Andrei,
Thanks for the info. I have updated the appropriate files.
So far so good, I haven't seen a deadlock since I applied the changes.
> Hi Shelby,
>
>> Can you provide details about what changes where made and the associated
>> revisions? As far as I know, we are pretty close to the CVS HEAD, but maybe
>> we missed something.
>
> You should have revision 1.4 of class DocumentAdapter
> (org.eclipse.dltk.internal.ui.editor package).
> If it is correct, then all try to rewrite built element logic.
>
> Andrei.
>>
>> It doesn't seem to be connected to any specific script or class. However,
>> the next time it happens I'll look at which files are being read in order to
>> confirm whether or not it is in a built-in.
>>
>> Thank You,
>> Shelby Sanders
>>
>>> Hi Shelby,
>>>
>>> Mikhail already fixed bug with Builtin elements.
>>>
>>> Actually We could not reproduce this bug. We tried to reproduce as you
>>> mentioned but it also works.
>>>
>>> Could you provide script on which it is happend?
>>>
>>> Thanks,
>>> Andrei.
>>>
>>>> Is there any further status on this issue?
>>>>
>>>> We have actually run into it in other cases now. The general idea being
>>>> that if the UI thread and any non-UI thread call RubyMixinModel.create**()
>>>> at the same time, there is a deadlock.
>>>>
>>>> The latest case is if you invoke code completion in the editor while your
>>>> mouse cursor is hovering. RubyCompletionEngine.completeClassMethods() is
>>>> called on the UI thread and AbstractScriptEditorTextHover.getHoverInfo() is
>>>> called in a worker thread.
>>>>
>>>> Thank You,
>>>> Shelby Sanders
>>>>
>>>>> Hello,
>>>>>
>>>>> I've investigated this problem. Problem source was really hard to find
>>>>> and was in that it's not possible to use DocumentAdapter for built-in
>>>>> source module's buffer. For standard source modules it's right, cause
>>>>> their contents will be set during initialization, so there will not be
>>>>> any need to call DocumentAdapter.setContents from non-ui thread. For
>>>>> built-in modules it is no so, because DocumentAdapter by it's design
>>>>> doesn't allow to set it's content not in ui thread without locking.
>>>>>
>>>>> By now I've changed DocumentAdapter to Buffer for built-in modules. It
>>>>> seems that it resolves a bug. But frankly speaking I'm not sure that it
>>>>> is a fully correct&beautiful solution, so I'd like to work more on it a
>>>>> bit later. By now you can update from cvs HEAD and get the changes.
>>>>>
>>>>>
>>>>> Mark Howe wrote:
>>>>>> We are experiencing a deadlock when we call the search engine when the
>>>>>> builder is running. For instance if we create a new project and
>>>>>> subsequently do a search for a type the ide deadlocks.
>>>>>>
>>>>>> The problem is that the AutoBuildJob uses the MixinBuilder to create
>>>>>> part of the index. But it uses a DocumentAdapter which trys to sync on
>>>>>> the UI thread. So if some other action is initiated from the UI thread
>>>>>> that requests a search, we get a deadlock when it hits the
>>>>>> ReadWriteMonitor.
>>>>>>
>>>>>> Look at SourceModule.getSourceAsCharArray() which causes
>>>>>> DocumentAdapter.setContents() which causes Display.syncExce();
>>>>>>
>>>>>> 1. Shouldn't builders avoid buffer usage or use a non-ui version?
>>>>>> 2. Is it ok to call the search engine from the UI thread, if not what is
>>>>>> the correct way?
>>>>>> 3. Are you using the same pattern as JDT?
>>>>>>
>>>>>> Thanks
>>>>>> Mark
>>>>>> (the two deadlocked threads)
>>>>>>
>>>>>> Thread [Worker-0] (Suspended)
>>>>>> Object.wait(long) line: not available [native method]
>>>>>> Semaphore.acquire(long) line: 43
>>>>>> UISynchronizer.syncExec(Runnable) line: 136
>>>>>> Display.syncExec(Runnable) line: 4097
>>>>>> DocumentAdapter$DocumentSetCommand.set(String) line: 103
>>>>>> DocumentAdapter.setContents(String) line: 404
>>>>>> DocumentAdapter.setContents(char[]) line: 382
>>>>>> BuiltinSourceModule.openBuffer(IProgressMonitor, Object) line: 218
>>>>>> BuiltinSourceModule.buildStructure(OpenableElementInfo,
>>>>>> IProgressMonitor, Map, IResource) line: 99
>>>>>> BuiltinSourceModule(Openable).generateInfos(Object, HashMap,
>>>>>> IProgressMonitor) line: 182
>>>>>> BuiltinSourceModule(ModelElement).openWhenClosed(Object,
>>>>>> IProgressMonitor) line: 166
>>>>>> BuiltinSourceModule(ModelElement).getElementInfo(IProgressMo nitor)
>>>>>> line: 154
>>>>>> BuiltinSourceModule(ModelElement).getElementInfo() line: 139
>>>>>> BuiltinSourceModule(Openable).getBuffer() line: 212
>>>>>> BuiltinSourceModule.getSource() line: 246
>>>>>> MixinBuilder.loadContent(ISourceModule) line: 81
>>>>>> MixinBuilder.buildModelElements(IScriptProject, List,
>>>>>> IProgressMonitor) line: 159
>>>>>> ScriptBuilder.buildElements(List, IProgressMonitor) line: 371
>>>>>> ScriptBuilder.fullBuild(IProgressMonitor) line: 259
>>>>>> ScriptBuilder.build(int, Map, IProgressMonitor) line: 159
>>>>>> BuildManager$2.run() line: 624
>>>>>> SafeRunner.run(ISafeRunnable) line: 37
>>>>>> BuildManager.basicBuild(int, IncrementalProjectBuilder, Map,
>>>>>> MultiStatus, IProgressMonitor) line: 166
>>>>>> BuildManager.basicBuild(IProject, int, ICommand[], MultiStatus,
>>>>>> IProgressMonitor) line: 197
>>>>>> BuildManager$1.run() line: 246
>>>>>> SafeRunner.run(ISafeRunnable) line: 37
>>>>>> BuildManager.basicBuild(IProject, int, MultiStatus,
>>>>>> IProgressMonitor) line: 249
>>>>>> BuildManager.basicBuildLoop(IProject[], IProject[], int,
>>>>>> MultiStatus, IProgressMonitor) line: 302
>>>>>> BuildManager.build(int, IProgressMonitor) line: 334
>>>>>> AutoBuildJob.doBuild(IProgressMonitor) line: 137
>>>>>> AutoBuildJob.run(IProgressMonitor) line: 235
>>>>>> Worker.run() line: 55
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thread [Worker-2] (Suspended)
>>>>>> Object.wait(long) line: not available [native method]
>>>>>> ReadWriteMonitor(Object).wait() line: 474
>>>>>> ReadWriteMonitor.enterRead() line: 30
>>>>>> PatternSearchJob.search(Index, IProgressMonitor) line: 146
>>>>>> PatternSearchJob.execute(IProgressMonitor) line: 77
>>>>>> IndexManager(JobManager).performConcurrentJob(IJob, int,
>>>>>> IProgressMonitor) line: 263
>>>>>> BasicSearchEngine.searchAllTypeNames(char[], int, char[], int, int,
>>>>>> IDLTKSearchScope,
>>>>>>
>>>>>> IRestrictedAccessTypeRequestor, int, IProgressMonitor) line: 876
>>>>>> SearchEngine.searchAllTypeNames(char[], int, char[], int, int,
>>>>>> IDLTKSearchScope, TypeNameMatchRequestor, int,
>>>>>>
>>>>>> IProgressMonitor) line: 484
>>>>>> called from UI thread
>>
Thank You,
Shelby Sanders
|
|
|
Goto Forum:
Current Time: Thu Apr 25 07:13:07 GMT 2024
Powered by FUDForum. Page generated in 0.03724 seconds |
] 
Search
Help
Register
Login
Home
