| UI-thread sleeping despite Runnables [message #521646] |
Thu, 18 March 2010 07:47  |
Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------070904020309040308070501
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Hi all,
from time to time the UI-thread in our RAP-application does not respond
any more. Like most multithreading issues this is not easy to reproduce.
However we managed to get the problem in debug mode and suspend the JVM.
The stack traces can explain that behavior:
The UI-thread sleeps (UIThread-Stack.txt) while there are runnables to
be executed. The second stack trace (NonUIThread-Stack.txt) is from
another thread that calls Display.syncExec(Runnable). Additionally, we
have appended some local variables of the two threads
(UIThread-LocVars.txt, NonUIThread-LocVars.txt). They show that both
threads are using the same display. The second set of local variables
(NonUIThread-LocVars.txt) lists the 4 runnables that are waiting to be
executed.
We suspect that some notifications miss the UI-thread due to missing
synchronisation but unfortunately the inter-thread communication
involving the UI-thread is quite complex in RAP. Therefore we were
unable to really track the problem.
We keep the JVM suspended for a few days if you need to know specific
details.
Thanks for your help,
Ulrich
--------------070904020309040308070501
Content-Type: text/plain;
name="UIThread-Stack.txt"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="UIThread-Stack.txt"
RGFlbW9uIFRocmVhZCBbVUlUaHJlYWQgWzk4OTlDOTc4MkQ2RTREMjUwREQz QTdBNjYyREZD
ODM1XV0gKFN1c3BlbmRlZCkJDQoJT2JqZWN0LndhaXQobG9uZykgbGluZTog bm90IGF2YWls
YWJsZSBbbmF0aXZlIG1ldGhvZF0gW2xvY2FsIHZhcmlhYmxlcyB1bmF2YWls YWJsZV0JDQoJ
VUlUaHJlYWQoT2JqZWN0KS53YWl0KCkgbGluZTogbm90IGF2YWlsYWJsZSBb bG9jYWwgdmFy
aWFibGVzIHVuYXZhaWxhYmxlXQkNCglVSVRocmVhZC5zd2l0Y2hUaHJlYWQo KSBsaW5lOiA1
MAkNCglSV1RMaWZlQ3ljbGUuc2xlZXAoKSBsaW5lOiAzMDYJDQoJRGlzcGxh eS5zbGVlcCgp
IGxpbmU6IDc5MAkNCglBcHBsaWNhdGlvbldvcmtiZW5jaEFkdmlzb3IoV29y a2JlbmNoQWR2
aXNvcikuZXZlbnRMb29wSWRsZShEaXNwbGF5KSBsaW5lOiAzNjEJDQoJV29y a2JlbmNoLnJ1
bkV2ZW50TG9vcChXaW5kb3ckSUV4Y2VwdGlvbkhhbmRsZXIsIERpc3BsYXkp IGxpbmU6IDI0
ODYJDQoJV29ya2JlbmNoLnJ1blVJKCkgbGluZTogMjQ0NAkNCglXb3JrYmVu Y2guYWNjZXNz
JDUoV29ya2JlbmNoKSBsaW5lOiAyMjk1CQ0KCVdvcmtiZW5jaCQ0LnJ1bigp IGxpbmU6IDUx
NAkNCglSZWFsbS5ydW5XaXRoRGVmYXVsdChSZWFsbSwgUnVubmFibGUpIGxp bmU6IDMzMgkN
CglXb3JrYmVuY2guY3JlYXRlQW5kUnVuV29ya2JlbmNoKERpc3BsYXksIFdv cmtiZW5jaEFk
dmlzb3IpIGxpbmU6IDQ5NwkNCglQbGF0Zm9ybVVJLmNyZWF0ZUFuZFJ1bldv cmtiZW5jaChE
aXNwbGF5LCBXb3JrYmVuY2hBZHZpc29yKSBsaW5lOiAxNTcJDQoJQXBwbGlj YXRpb24uY3Jl
YXRlVUkoKSBsaW5lOiAxOTIJDQoJRW50cnlQb2ludE1hbmFnZXIuY3JlYXRl VUkoU3RyaW5n
KSBsaW5lOiA5MgkNCglSV1RMaWZlQ3ljbGUuY3JlYXRlVUkoKSBsaW5lOiAy MzEJDQoJUldU
TGlmZUN5Y2xlJFVJVGhyZWFkQ29udHJvbGxlci5ydW4oKSBsaW5lOiAxMTkJ DQoJVUlUaHJl
YWQoVGhyZWFkKS5ydW4oKSBsaW5lOiBub3QgYXZhaWxhYmxlCQ0K
--------------070904020309040308070501
Content-Type: text/plain;
name="NonUIThread-Stack.txt"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="NonUIThread-Stack.txt"
RGFlbW9uIFRocmVhZCBbQ2xpZW50LVdvcmtsaXN0VXBkYXRlTm90aWZpZXJd IChTdXNwZW5k
ZWQpCQ0KCU9iamVjdC53YWl0KGxvbmcpIGxpbmU6IG5vdCBhdmFpbGFibGUg W25hdGl2ZSBt
ZXRob2RdIFtsb2NhbCB2YXJpYWJsZXMgdW5hdmFpbGFibGVdCQ0KCU9iamVj dC53YWl0KCkg
bGluZTogbm90IGF2YWlsYWJsZSBbbG9jYWwgdmFyaWFibGVzIHVuYXZhaWxh YmxlXQkNCglV
SUNhbGxCYWNrTWFuYWdlciRTeW5jUnVubmFibGUuYmxvY2soKSBsaW5lOiAz MDcJDQoJVUlD
YWxsQmFja01hbmFnZXIuYWRkU3luYyhEaXNwbGF5LCBSdW5uYWJsZSkgbGlu ZTogMTIyCQ0K
CURpc3BsYXkkMi5ydW4oKSBsaW5lOiA2OTUJDQoJVUlDYWxsQmFja1NlcnZp Y2VIYW5kbGVy
LnJ1bk5vblVJVGhyZWFkV2l0aEZha2VDb250ZXh0KERpc3BsYXksIFJ1bm5h YmxlKSBsaW5l
OiA0NjAJDQoJVUlDYWxsQmFjay5ydW5Ob25VSVRocmVhZFdpdGhGYWtlQ29u dGV4dChEaXNw
bGF5LCBSdW5uYWJsZSkgbGluZTogNDQJDQoJRGlzcGxheS5zeW5jRXhlYyhS dW5uYWJsZSkg
bGluZTogNjkzCQ0KCVdvcmtzcGFjZU5hdmlnYXRvclZpZXcuaXRlbXNDaGFu Z2VkKCkgbGlu
ZTogNTEzCQ0KCVdvcmtsaXN0VGFibGVXaWRnZXRQcm92aWRlcihEZWZhdWx0 VGFibGVXaWRn
ZXRQcm92aWRlcikucGVyZm9ybVVwZGF0ZSgpIGxpbmU6IDU3CQ0KCVdvcmts aXN0VGFibGVX
aWRnZXRQcm92aWRlci53b3JrbGlzdFVwZGF0ZWQoQ2xpZW50V29ya2xpc3Qs IFdvcmtsaXN0
VXBkYXRlKSBsaW5lOiA2ODQJDQoJRGVmYXVsdENsaWVudFdvcmtsaXN0LnJ1 bigpIGxpbmU6
IDI0MQkNCglUaHJlYWQucnVuKCkgbGluZTogbm90IGF2YWlsYWJsZQkNCg==
--------------070904020309040308070501
Content-Type: text/plain;
name="UIThread-LocVars.txt"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="UIThread-LocVars.txt"
RGlzcGxheS5zbGVlcCgpIGxpbmU6IDc5MAkNCg0KdGhpcwlEaXNwbGF5ICAo aWQ9MzI5MSkJ
DQoJYWN0aXZlU2hlbGwJU2hlbGwgIChpZD04MDk0KQkNCglib3VuZHMJUmVj dGFuZ2xlICAo
aWQ9ODA5NSkJDQoJZGF0YQludWxsCQ0KCWRpc3BsYXlBZGFwdGVyCURpc3Bs YXkkRGlzcGxh
eUFkYXB0ZXIgIChpZD04MDk2KQkNCglkaXNwb3NlZAlmYWxzZQkNCglmaWx0 ZXJzCUFycmF5
TGlzdDxFPiAgKGlkPTgyOTIpCQ0KCWZvY3VzQ29udHJvbAlQYWdlQm9vayAg KGlkPTgyOTMp
CQ0KCWtleXMJbnVsbAkNCgltb25pdG9yCU1vbml0b3IgIChpZD04Mjk0KQkN CglzZXNzaW9u
CVNlc3Npb25TdG9yZUltcGwgIChpZD04Mjk1KQkNCglzaGVsbHMJQXJyYXlM aXN0PEU+ICAo
aWQ9ODI5NikJDQoJdGhyZWFkCVVJVGhyZWFkICAoaWQ9MjQ2MykJDQoJdmFs dWVzCW51bGwJ
DQoJd2lkZ2V0QWRhcHRlcglXaWRnZXRBZGFwdGVyICAoaWQ9ODMwNykJDQps aWZlQ3ljbGUJ
UldUTGlmZUN5Y2xlICAoaWQ9MzI1OCkJDQo=
--------------070904020309040308070501
Content-Type: text/plain;
name="NonUIThread-LocVars.txt"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="NonUIThread-LocVars.txt"
VUlDYWxsQmFja01hbmFnZXIuYWRkU3luYyhEaXNwbGF5LCBSdW5uYWJsZSkg bGluZTogMTIy
DQoNCnRoaXMJVUlDYWxsQmFja01hbmFnZXIgIChpZD0zMjg5KQkNCglhY3Rp dmUJdHJ1ZQkN
Cglsb2NrZWQJSGFzaFNldDxFPiAgKGlkPTgxMDkpCQ0KCXJ1bm5hYmxlcwlB cnJheUxpc3Q8
RT4gIChpZD04MTA2KQkNCgkJZWxlbWVudERhdGEJT2JqZWN0WzEwXSAgKGlk PTgxMDcpCQ0K
CQkJWzBdCVVJQ2FsbEJhY2tNYW5hZ2VyJFJ1bm5hYmxlQmFzZSAgKGlkPTgx MTEpCQ0KCQkJ
CXJ1bm5hYmxlCVNXVFZpZXcyJFNXVFZpZXdQYXJ0JDEgIChpZD04MjM5KQkN CgkJCQkJdGhp
cyQxCVNXVFZpZXcyJFNXVFZpZXdQYXJ0ICAoaWQ9ODI0MCkJDQoJCQlbMV0J VUlDYWxsQmFj
a01hbmFnZXIkUnVubmFibGVCYXNlICAoaWQ9ODExMikJDQoJCQkJcnVubmFi bGUJVGFibGVX
aWRnZXQkMSAgKGlkPTgyNTMpCQ0KCQkJCQl0aGlzJDAJVGFibGVXaWRnZXQg IChpZD04MjU0
KQkNCgkJCVsyXQlVSUNhbGxCYWNrTWFuYWdlciRTeW5jUnVubmFibGUgIChp ZD0zMjg4KQkN
CgkJCQlsb2NrCU9iamVjdCAgKGlkPTMyODcpCQ0KCQkJCXJ1bm5hYmxlCVdv cmtzcGFjZU5h
dmlnYXRvclZpZXckNSAgKGlkPTgwODYpCQ0KCQkJCXRlcm1pbmF0ZWQJZmFs c2UJDQoJCQlb
M10JVUlDYWxsQmFja01hbmFnZXIkUnVubmFibGVCYXNlICAoaWQ9ODExMykJ DQoJCQkJcnVu
bmFibGUJU1dUVmlldzIkU1dUVmlld1BhcnQkMSAgKGlkPTgyNTUpCQ0KCQkJ CQl0aGlzJDEJ
U1dUVmlldzIkU1dUVmlld1BhcnQgIChpZD04MjU2KQkNCgkJCVs0XQludWxs CQ0KCQkJWzVd
CW51bGwJDQoJCQlbNl0JbnVsbAkNCgkJCVs3XQludWxsCQ0KCQkJWzhdCW51 bGwJDQoJCQlb
OV0JbnVsbAkNCgkJbW9kQ291bnQJMjg4NAkNCgkJc2l6ZQk0CQ0KCXJ1bm5h Ymxlc0xvY2sJ
T2JqZWN0ICAoaWQ9ODEwOCkJDQoJdWlUaHJlYWRSdW5uaW5nCWZhbHNlCQ0K CXdhaXRGb3JV
SVRocmVhZAl0cnVlCQ0KZGlzcGxheQlEaXNwbGF5ICAoaWQ9MzI5MSkJDQpy dW5uYWJsZQlX
b3Jrc3BhY2VOYXZpZ2F0b3JWaWV3JDUgIChpZD04MDg2KQkNCnN5bmNSdW5u YWJsZQlVSUNh
bGxCYWNrTWFuYWdlciRTeW5jUnVubmFibGUgIChpZD0zMjg4KQkNCg==
--------------070904020309040308070501--
|
|
|
|
| Re: UI-thread sleeping despite Runnables [message #522462 is a reply to message #522446] |
Mon, 22 March 2010 13:32  |
| Eclipse User |
|
|
|
Hi Rüdiger,
I am not sure whether this is the same bug, we do not have a modal
context at all but a lot of calls to Display.syncExec(Runnable) that are
caused by updates on the server side our RAP-application is a client of.
That is, we have a lot of updates for the callback request and very
few direct service requests from the browser side.
Currently I am investigating our problem since it is very critical for
our application. I found the waitForUIThread-flag in the
UICallBackManager being true (see attachment NonUIThread-LocVars.txt of
my last post). This will block the callback request even if there are
runnables – runnables.isEmpty() is not checked at all in
mustBlockCallBackRequest(). However, as I understand it right now, this
should not happen at all.
As soon as I can provide more details on the strange value of the flag,
I will file a new bug.
Thanks for your help,
Ulrich
Rüdiger Herrmann schrieb:
> Ulrich,
>
> thanks for the detailed report. You probably ran into this bug:
> 280187: ModalContext removes UICallback too early
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=280187
> However, it would be much appreciated if you could file another
> bugzilla, as the one mentioned isn't very focused.
> We will address this issue towards the end of the 1.3 development cycle.
>
> TIA
> Rüdiger
|
|
|
|
| Re: UI-thread sleeping despite Runnables [message #530042 is a reply to message #524102] |
Wed, 28 April 2010 05:33 |
| Eclipse User |
|
|
|
Ulrich,
we finally found the time to address bugs related to (a)syncExec and the
UICallback.
We think the problem that you describe is solved with these changes.
Please also see the comment on bug 307048
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=307048> (Deadlock due to
UI-thread sleeping despite runnables).
Regards
Rüdiger
--
Rüdiger Herrmann
http://eclipsesource.com
On 30.03.2010 19:10, Ulrich Kreher wrote:
> Since the occured deadlock renders our application unusable (it can
> occur several times in one hour), we investigated our problem some more:
>
> The patch I filed for the waitForUIThread-flag
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=307048) does not solve
> the deadlock. Therefore we logged the UI-Thread starting and ending, the
> callback request entering and leaving (all in the UICallBackManager) as
> well as all service requests arriving (in ServiceManager) – see the
> attached ThreadLogs.txt. Additionally we used Wireshark to log the
> HTTP-traffic expecting some lost messages.
> Changing the Eclipse-View in our RAP-application (using IE8) triggered a
> timed update and the complete UI froze immediately after changing the
> view. We suspended the JVM and created the stacktraces. They indicate
> that we have the very same deadlock again, that is the callback thread
> waiting for the UI-Thread (see CallbackThread-Stack.txt), having
> runnables (this time a TimerRunnable, see CallbackThread-LocVars.txt)
> and the UI-Thread waiting for a service request (see UIThread.txt).
>
> We found another thread having an interesting stack trace: A service
> request was doing some POST-retrieval right before “servicing” (see
> POSTThread-Stack.txt). Probably this is the thread to wake up the
> UI-Thread but unfortunately its stuck trying to read the POST-message –
> this should be the last message Wireshark logged (see HTTP-Traffic.txt).
>
> We would really appreciate someone having deeper RAP-knowledge to tell
> us, whether this POST-retrieval is intended and/or could be the cause
> for the deadlock. This may help in narrowing down this bug (assumed it
> is one).
>
> Many thanks,
>
> Ulrich
|
|
|
Powered by
FUDForum. Page generated in 0.05301 seconds
Home