Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Remote Application Platform (RAP) » RAP 1.3RC3: deadlock detected
RAP 1.3RC3: deadlock detected [message #539016] Wed, 09 June 2010 10:42 Go to next message
Dmitry Pryadkin is currently offline Dmitry PryadkinFriend
Messages: 146
Registered: July 2009
Senior Member
Hello Everybody,

Display.dispose and Display#isDisposed both acquire the Display#deviceLock.

The calls to Display#dispose and Display#isDisposed are in separate
threads (stacktrace follows).

Deadlock finally occurs in JobManager - JobManager#select and
JobManager#endJob both acquire the JobManager#lock.

Daemon Thread [UIThread [1mf5jlvjysproowtxhc1f0krn]] (Suspended)
JobManager.select(Object, int) line: 1158
JobManager.select(Object) line: 1148
JobManager.cancel(Object) line: 333
Workbench.cancelEarlyStartup() line: 2769
Workbench.shutdown() line: 2734
Workbench.busyClose(boolean) line: 870
Workbench.access$12(Workbench, boolean) line: 781
Workbench$21.run() line: 1047
BusyIndicator.showWhile(Display, Runnable) line: 66
Workbench.close(int, boolean) line: 1045
Workbench.close() line: 1007
Workbench$ShutdownHandler.handleEvent(Event) line: 131
Display.sendDisposeEvent() line: 714
Display.release() line: 693
Display(Device).dispose() line: 282
UIThread.processShutdown() line: 159
RWTLifeCycle$UIThreadController.run() line: 128
UIThread(Thread).run() line: 619
UIThread.run() line: 102



Thread [Worker-0] (Suspended)
Display(Device).isDisposed() line: 300
JobManagerAdapter.done(IJobChangeEvent) line: 119
JobListeners$3.notify(IJobChangeListener, IJobChangeEvent) line:39
JobListeners.doNotify(JobListeners$IListenerDoit, IJobChangeEvent)
line: 96
JobListeners.done(Job, IStatus, boolean) line: 152
JobManager.endJob(InternalJob, IStatus, boolean) line: 646
WorkerPool.endJob(InternalJob, IStatus) line: 105
Worker.run() line: 71

Dmitry
Re: RAP 1.3RC3: deadlock detected [message #539267 is a reply to message #539016] Thu, 10 June 2010 08:32 Go to previous messageGo to next message
Ralf Sternberg is currently offline Ralf SternbergFriend
Messages: 1313
Registered: July 2009
Senior Member

Hi Dmitry,

is this deadlock reproducible with your application or does it only
occur randomly? Can you provide some code or explain the preconditions
that cause the deadlock?

Regards, Ralf

Dmitry Pryadkin wrote:
> Hello Everybody,
>
> Display.dispose and Display#isDisposed both acquire the Display#deviceLock.
>
> The calls to Display#dispose and Display#isDisposed are in separate
> threads (stacktrace follows).
>
> Deadlock finally occurs in JobManager - JobManager#select and
> JobManager#endJob both acquire the JobManager#lock.
>
> Daemon Thread [UIThread [1mf5jlvjysproowtxhc1f0krn]] (Suspended)
> JobManager.select(Object, int) line: 1158
> JobManager.select(Object) line: 1148
> JobManager.cancel(Object) line: 333
> Workbench.cancelEarlyStartup() line: 2769
> Workbench.shutdown() line: 2734
> Workbench.busyClose(boolean) line: 870
> Workbench.access$12(Workbench, boolean) line: 781
> Workbench$21.run() line: 1047
> BusyIndicator.showWhile(Display, Runnable) line: 66
> Workbench.close(int, boolean) line: 1045
> Workbench.close() line: 1007
> Workbench$ShutdownHandler.handleEvent(Event) line: 131
> Display.sendDisposeEvent() line: 714
> Display.release() line: 693
> Display(Device).dispose() line: 282
> UIThread.processShutdown() line: 159
> RWTLifeCycle$UIThreadController.run() line: 128
> UIThread(Thread).run() line: 619
> UIThread.run() line: 102
>
>
>
> Thread [Worker-0] (Suspended)
> Display(Device).isDisposed() line: 300
> JobManagerAdapter.done(IJobChangeEvent) line: 119
> JobListeners$3.notify(IJobChangeListener, IJobChangeEvent) line:39
> JobListeners.doNotify(JobListeners$IListenerDoit, IJobChangeEvent)
> line: 96
> JobListeners.done(Job, IStatus, boolean) line: 152
> JobManager.endJob(InternalJob, IStatus, boolean) line: 646
> WorkerPool.endJob(InternalJob, IStatus) line: 105
> Worker.run() line: 71
>
> Dmitry
Re: RAP 1.3RC3: deadlock detected [message #539295 is a reply to message #539267] Thu, 10 June 2010 09:22 Go to previous messageGo to next message
Dmitry Pryadkin is currently offline Dmitry PryadkinFriend
Messages: 146
Registered: July 2009
Senior Member
Hi Ralf,

It happens with my application. I can't pin-point the situation within
small project.

Steps to reproduce:

1) Start Application
2) Open session
3) Do some things - populate Jobs in Jobmanager
4) Close browser
5) Wait for session invalidation
6) Some jobs (with JobListeners) left spinning in JobManager
8) The thread named "Worker-0" had attempted to end one of these jobs,
but got caught in Display#isDisposed (see 2nd stacktrace).
9) In the same time the UI Thread was about to do Display#dispose (see
1st stacktrace).

I don't know from where the "Worker-0" was created. But I believe it's
from Workbench.

Dmitry

Ralf Sternberg wrote:
> Hi Dmitry,
>
> is this deadlock reproducible with your application or does it only
> occur randomly? Can you provide some code or explain the preconditions
> that cause the deadlock?
>
> Regards, Ralf
>
> Dmitry Pryadkin wrote:
>> Hello Everybody,
>>
>> Display.dispose and Display#isDisposed both acquire the Display#deviceLock.
>>
>> The calls to Display#dispose and Display#isDisposed are in separate
>> threads (stacktrace follows).
>>
>> Deadlock finally occurs in JobManager - JobManager#select and
>> JobManager#endJob both acquire the JobManager#lock.
Re: RAP 1.3RC3: deadlock detected [message #539467 is a reply to message #539295] Thu, 10 June 2010 20:35 Go to previous messageGo to next message
Ralf Sternberg is currently offline Ralf SternbergFriend
Messages: 1313
Registered: July 2009
Senior Member

Hi Dmitry,

I can't currently reproduce a deadlock with your description. The UI
Threads always terminate properly, even when the browser is closed while
some jobs are still running.

If you can reproduce it, you should open a bug report but we'll need
some more information. The stacktraces alone will not be sufficient to
analyze the problem.

Regards, Ralf

Dmitry Pryadkin wrote:
> Hi Ralf,
>
> It happens with my application. I can't pin-point the situation within
> small project.
>
> Steps to reproduce:
>
> 1) Start Application
> 2) Open session
> 3) Do some things - populate Jobs in Jobmanager
> 4) Close browser
> 5) Wait for session invalidation
> 6) Some jobs (with JobListeners) left spinning in JobManager
> 8) The thread named "Worker-0" had attempted to end one of these jobs,
> but got caught in Display#isDisposed (see 2nd stacktrace).
> 9) In the same time the UI Thread was about to do Display#dispose (see
> 1st stacktrace).
>
> I don't know from where the "Worker-0" was created. But I believe it's
> from Workbench.
>
> Dmitry
>
> Ralf Sternberg wrote:
>> Hi Dmitry,
>>
>> is this deadlock reproducible with your application or does it only
>> occur randomly? Can you provide some code or explain the preconditions
>> that cause the deadlock?
>>
>> Regards, Ralf
>>
>> Dmitry Pryadkin wrote:
>>> Hello Everybody,
>>>
>>> Display.dispose and Display#isDisposed both acquire the
>>> Display#deviceLock.
>>>
>>> The calls to Display#dispose and Display#isDisposed are in separate
>>> threads (stacktrace follows).
>>>
>>> Deadlock finally occurs in JobManager - JobManager#select and
>>> JobManager#endJob both acquire the JobManager#lock.
Re: RAP 1.3RC3: deadlock detected [message #539530 is a reply to message #539016] Fri, 11 June 2010 08:27 Go to previous messageGo to next message
Yury Mising name is currently offline Yury Mising nameFriend
Messages: 95
Registered: May 2010
Location: Russia
Member
Hi, all!

I'd reproduced this bug too, but can not give any description how to reproduce it again. It happens with me once and never see again. Just want to say that this is not only Dmitry's problem.

Yury.
Re: RAP 1.3RC3: deadlock detected [message #547308 is a reply to message #539016] Fri, 16 July 2010 09:36 Go to previous messageGo to next message
Yury Mising name is currently offline Yury Mising nameFriend
Messages: 95
Registered: May 2010
Location: Russia
Member
Hi all!

I've got this deadlock again.
Seems we should find a better way to dispose display in UIThread.processShutdwon

  public void processShutdown() {
    updateServiceContext();
    try {
      // Simulate PROCESS_ACTION phase if the session times out
      CurrentPhase.set( PhaseId.PROCESS_ACTION );
      // TODO [rh] find a better decoupled way to dispose of the display
      Display display = RWTLifeCycle.getSessionDisplay();
      if( display != null ) {
        display.dispose();
      }
      shutdownCallback.run();
    } finally {
      ContextProvider.disposeContext();
    }
  }


display.dispose start and invoke some workbench.close() listeners that cancel current running jobs.
I agree with Dmitry that it is hard to create a snippet to reproduce, but TODO comment make me think that this problem is not forced and has rights to existence.

Best regards,
Yury.
icon5.gif  Re: RAP 1.3RC3: deadlock detected [message #665970 is a reply to message #547308] Mon, 18 April 2011 12:13 Go to previous messageGo to next message
Oliver Probst is currently offline Oliver ProbstFriend
Messages: 4
Registered: April 2011
Junior Member
Hi,

we've got exactly the same problem in our application. Reproducing it on a test environment wasn't successful, but the server stuck every few sessions.

During the session clean-up, the UIThread waits for a Worker Thread which waits for the UIThread again.
Blocked with the workbench shutdown thread is a thread which tries to notify for a DecorationScheduler job notification.

New sessions are also waiting when PlatformUI.createAndRunWorkbench(...) is called.

We are using RAP 1.3.1.
The stack traces are similar to Dmitry Pryadkins post.

So are there any experiences how to handle this problem?
Is there a workaround available?
Or is this problem already solved in future versions of RAP?
Someone further ideas about this topic?

Thanks,
Oliver

Re: RAP 1.3RC3: deadlock detected [message #665998 is a reply to message #539016] Mon, 18 April 2011 14:35 Go to previous messageGo to next message
Oliver Pfau is currently offline Oliver PfauFriend
Messages: 28
Registered: July 2009
Junior Member
Probably I have the same:

http://www.eclipse.org/forums/index.php?t=msg&th=207611& amp;start=0&S=f538b16b8e265ac85b25d7a9f19f0341
Re: RAP 1.3RC3: deadlock detected [message #669974 is a reply to message #665970] Thu, 12 May 2011 08:33 Go to previous messageGo to next message
Oliver Probst is currently offline Oliver ProbstFriend
Messages: 4
Registered: April 2011
Junior Member
Hi,

the problem looks very similar to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=341849.

I'll try the patch provided by Gareth Bowen to verfiy this.

Oliver
Re: RAP 1.3RC3: deadlock detected [message #671317 is a reply to message #669974] Tue, 17 May 2011 13:19 Go to previous message
Oliver Probst is currently offline Oliver ProbstFriend
Messages: 4
Registered: April 2011
Junior Member
Hello again,

I had some time left for further investigations and I think I found our
problem.

Unfortunately the patch referenced in my former post wasn't successful.
But this gave me the chance to examine the stack traces again (attached).

The problem is that we have some kind of editable cells in a table. The
deadlock occur when:
1. The user enters a value into a editable table cell.
2. The user don't apply the change by pressing "return".
3. The session expires.

This leads to a ICellEditorListener#applyEditorValue(). This event
triggers a refresh of another derived ViewPart#refresh() object which is
another view of the same data model:

Daemon Thread [UIThread...:
....
TreeViewer(StructuredViewer).refresh() line: 1445
ConfigurationOverview.refresh() line: 386
ConfigurationOverview.configProblemsChanged() line: 133
ConfigurationListenerHandling.configProblemsChanged() line: 100
Configuration.validateConfiguration() line: 869
PropertyView$PropEditingSupport.setValue(Object, Object) line: 178
PropertyView$PropEditingSupport(EditingSupport).saveCellEdit orValue(CellEditor,
ViewerCell) line: 116
TableViewerEditor(ColumnViewerEditor).saveEditorValue(CellEd itor) line: 454
TableViewerEditor(ColumnViewerEditor).applyEditorValue() line: 310
...
UIThread.processShutdown() line: 159


This refresh triggers a DecorationScheduler#decorationJob#schedule()
which waits for "JobManager#lock" and locks "Device#deviceLock".

The same time the Worker-11 Thread waits for "Device#deviceLock" and
blocks "JobManager#lock".

I'm not sure if this is a problem of RAP or of a missing decoupling of
our views. I'll do further investigations. :-)

I hope this description might help some other users having similar problems.

Regards,
Oliver




Complete stack traces:


__Worker Thread_______________________________

Thread [Worker-11] (Suspended)
owns: Object (id=14665)
waiting for: Object (id=14664)
owned by: Daemon Thread [UIThread
[62A33EC05149C56A5A094BAAE07985E6.localSlot2]] (Suspended)
waiting for: Object (id=14665)
owned by: Thread [Worker-11] (Suspended)
waiting for: Object (id=14664)
Display(Device).isDisposed() line: 300
JobManagerAdapter.done(IJobChangeEvent) line: 119
JobListeners$3.notify(IJobChangeListener, IJobChangeEvent) line: 39
JobListeners.doNotify(JobListeners$IListenerDoit, IJobChangeEvent)
line: 96
JobListeners.done(Job, IStatus, boolean) line: 152
JobManager.endJob(InternalJob, IStatus, boolean) line: 647
JobManager.startJob() line: 1488
WorkerPool.startJob(Worker) line: 218
Worker.run() line: 50

__UI Thread_______________________________

Daemon Thread [UIThread [62A33EC05149C56A5A094BAAE07985E6.localSlot2]]
(Suspended)
owns: DecorationScheduler (id=14663)
owns: Object (id=14664)
waiting for: Object (id=14665)
owned by: Thread [Worker-11] (Suspended)
waiting for: Object (id=14664)
owned by: Daemon Thread [UIThread
[62A33EC05149C56A5A094BAAE07985E6.localSlot2]] (Suspended)
JobManager.schedule(InternalJob, long, boolean) line: 1109
DecorationScheduler$4(InternalJob).schedule(long) line: 427
DecorationScheduler$4(Job).schedule() line: 436
DecorationScheduler$2.run() line: 177
FakeContextUtil.runNonUIThreadWithFakeContext(Display, Runnable) line: 60
UICallBack.runNonUIThreadWithFakeContext(Display, Runnable) line: 48
DecorationScheduler.queueForDecoration(Object, Object, boolean, String,
IDecorationContext) line: 175
DecoratorManager.prepareDecoration(Object, String, IDecorationContext)
line: 1141
DecoratorManager$ManagedWorkbenchLabelDecorator.prepareDecor ation(Object, String, IDecorationContext) line: 177
DecoratingLabelProvider.updateLabel(ViewerLabel, TreePath) line: 327
WrappedViewerLabelProvider.update(ViewerCell) line: 183
ColumnViewer$3(ViewerColumn).refresh(ViewerCell) line: 153
TreeViewer(AbstractTreeViewer).doUpdateItem(Item, Object) line: 916
AbstractTreeViewer$UpdateItemSafeRunnable.run() line: 102
SafeRunner.run(ISafeRunnable) line: 42
Platform.run(ISafeRunnable) line: 888
JFaceUtil$1.run(ISafeRunnable) line: 50
SafeRunnable.run(ISafeRunnable) line: 175
TreeViewer(AbstractTreeViewer).doUpdateItem(Widget, Object, boolean)
line: 996
StructuredViewer$UpdateItemSafeRunnable.run() line: 481
SafeRunner.run(ISafeRunnable) line: 42
Platform.run(ISafeRunnable) line: 888
JFaceUtil$1.run(ISafeRunnable) line: 50
SafeRunnable.run(ISafeRunnable) line: 175
TreeViewer(StructuredViewer).updateItem(Widget, Object) line: 2142
TreeViewer(AbstractTreeViewer).updateChildren(Widget, Object, Object[],
boolean) line: 2671
TreeViewer(AbstractTreeViewer).internalRefreshStruct(Widget, Object,
boolean) line: 1849
TreeViewer.internalRefreshStruct(Widget, Object, boolean) line: 717
TreeViewer(AbstractTreeViewer).internalRefreshStruct(Widget, Object,
boolean) line: 1856
TreeViewer.internalRefreshStruct(Widget, Object, boolean) line: 717
TreeViewer(AbstractTreeViewer).internalRefresh(Widget, Object, boolean,
boolean) line: 1824
TreeViewer(AbstractTreeViewer).internalRefresh(Object, boolean) line: 1781
TreeViewer(AbstractTreeViewer).internalRefresh(Object) line: 1767
StructuredViewer$7.run() line: 1488
TreeViewer(StructuredViewer).preservingSelection(Runnable, boolean)
line: 1423
TreeViewer.preservingSelection(Runnable, boolean) line: 403
TreeViewer(StructuredViewer).preservingSelection(Runnable) line: 1384
TreeViewer(StructuredViewer).refresh(Object) line: 1486
TreeViewer(ColumnViewer).refresh(Object) line: 547
TreeViewer(StructuredViewer).refresh() line: 1445
ConfigurationOverview.refresh() line: 386
ConfigurationOverview.configProblemsChanged() line: 133
ConfigurationListenerHandling.configProblemsChanged() line: 100
Configuration.validateConfiguration() line: 869
PropertyView$PropEditingSupport.setValue(Object, Object) line: 178
PropertyView$PropEditingSupport(EditingSupport).saveCellEdit orValue(CellEditor, ViewerCell) line: 116
TableViewerEditor(ColumnViewerEditor).saveEditorValue(CellEd itor)
line: 454
TableViewerEditor(ColumnViewerEditor).applyEditorValue() line: 310
ColumnViewerEditor$2.applyEditorValue() line: 152
CellEditor$1.run() line: 329
SafeRunner.run(ISafeRunnable) line: 42
Platform.run(ISafeRunnable) line: 888
JFaceUtil$1.run(ISafeRunnable) line: 50
SafeRunnable.run(ISafeRunnable) line: 175
TextCellEditor(CellEditor).fireApplyEditorValue() line: 327
TextCellEditor(CellEditor).focusLost() line: 708
TextCellEditor$5.focusLost(FocusEvent) line: 184
FocusEvent.dispatchToObserver(Object) line: 70
FocusEvent(Event).processEvent() line: 44
FocusEvent(TypedEvent).processEvent() line: 161
Display.setFocusControl(Control) line: 287
Display.access$3(Display, Control) line: 282
Display$DisplayAdapter.setFocusControl(Control) line: 2247
Composite(Control).setFocusControl(Control) line: 2127
Composite(Control).forceFocus() line: 758
Composite(Control).setFixedFocus() line: 2182
Composite(Control).fixFocus(Control) line: 2165
Composite(Control).setVisible(boolean) line: 259
WorkbenchPage.onDeactivate() line: 2508
WorkbenchWindow$22.run() line: 2912
BusyIndicator.showWhile(Display, Runnable) line: 66
WorkbenchWindow.setActivePage(IWorkbenchPage) line: 2907
WorkbenchWindow.closeAllPages() line: 798
WorkbenchWindow.hardClose() line: 1635
WorkbenchWindow.busyClose() line: 683
WorkbenchWindow.access$0(WorkbenchWindow) line: 659
WorkbenchWindow$2.run() line: 775
BusyIndicator.showWhile(Display, Runnable) line: 66
WorkbenchWindow.close() line: 773
WindowManager.close() line: 109
Workbench$13.run() line: 861
SafeRunner.run(ISafeRunnable) line: 42
Workbench.busyClose(boolean) line: 858
Workbench.access$12(Workbench, boolean) line: 781
Workbench$21.run() line: 1047
BusyIndicator.showWhile(Display, Runnable) line: 66
Workbench.close(int, boolean) line: 1045
Workbench.close() line: 1007
Workbench$ShutdownHandler.handleEvent(Event) line: 131
Display.sendDisposeEvent() line: 714
Display.release() line: 693
Display(Device).dispose() line: 282
UIThread.processShutdown() line: 159
RWTLifeCycle$UIThreadController.run() line: 139
UIThread(Thread).run() line: 619
UIThread.run() line: 102
Previous Topic:"TypeError - $0 is undefined" by gmaps Example.
Next Topic:Upgrade from RAP 1.2.1 to 1.2.2 because of Firefox 3.6 - possible WAR deployment procedure problem
Goto Forum:
  


Current Time: Thu Mar 28 22:07:19 GMT 2024

Powered by FUDForum. Page generated in 0.03864 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top