UI freezes when a ThreadJob is waiting to run in the UI Thread #40
Comments
|
it's not blocking. its a wait(250) =>will update UI at least every 250ms, see also the comments 3 lines below "This thread may be interrupted via two common scenarios.." |
|
actually this whole refactoring issue is just a duplicate of Bug 578871 |
|
Whatever it does, my eclipse is stuck, if I try to use any UI control my OS says the application is not responding and the only option is to forcefully kill the application, so it seems it is stuck in this block: |
yes, that why i demand to fix it: eclipse-jdt/eclipse.jdt.ui#19 |
I do not see any code in this while loop that actually updates the UI, that is calling |
|
yea, thats like magic in the blocker handler. How about you test my proposed fix for your situation? |
Can you give a code reference to this magic? |
|
use the patch and set a breakpoint at the method you search for. |
I don't think this is related here. This is not an UI freeze, it simply never finish, the Job is just waiting forever (whether its timed or not does not matter here) in |
|
You complain "The Progress View freezes" and on the other hand say "This is not an UI freeze". contradictory. Regarding the endless build loop you may want to debug why the build is triggered again. maybe this commits helps: |
Just keep the context and it is not that 'contradictory' at all. Bug 578871 states that "UNDO does not show Cancel Dialog but freezes till autobuild finished" and that's what is reported by Eclipse as "UIFreeze", the UI is unresponsive for some time and then you can work again. What I described here is that the progress view is constantly performing tasks (most likely m2e fault), and the suddenly get stuck, it shows a progress of 50%, but nothing happens anymore and the main thread is waiting forever that this Job is about to run. The application is now freezed but never get working again (or I'm not patient). Beside that you explained that the timed wait is actually there to not freezed but at least I can't perform any actions including closing the application. So maybe there is a bug in the code (independent vom JDT) but Bug 578871 just triggers/makes this behavior visible... Don't get me wrong, maybe this could be fixed by Bug 578871 but then the general problem remains and other code can get stuck here as well... My problem is that one can't really reliable reproduce the issue, it just "happens" from time to time (especially ofte do not happen when creating a new workspace, vanishes when you refresh a certain project or appears when switching branches) so its really hard to debug and I can only hope giving some vague hints hoping the right things get fixed to it once vanish :-) |
|
IIRC I have seen issues with projects dependencies wrongly calculated in the past. Unfortunately I forgot which tracing option was the best to idenfy these. Maybe build/cycle or build/needbuild?
|
|
See also here for the information how to enable this trace flags to your regular IDE. https://www.vogella.com/tutorials/EclipsePerformance/article.html#using-the-build-in-tracing-facilities-of-eclipse I typically pipe the log output of such an Eclipse into an file so that I can look at these later if needed. |
|
Please separate the Problems: that 1 and 2 occurs on the same time only makes the problem "only" even worse. So which of the both do you want to track with this github issue?
|
3.) Job is never run one and two does not occur at the same time. 1 occurs just if 2 is spanning many new tasks no idea if its also triggering autobuilds ... I simply don't want the Job API to freeze (whatever the UI, a job) forever regardless what code triggered a job ... so to make this more concrete: It seems the UI freezes when a ThreadJob is waiting to run. If you can reproduce the issue with some other code as well fine, but that's nothing to solve by m2e or jdt. |
laeubi
changed the title
But the stacktrace you posted is as in bug 578871. |
|
Maybe the job tracing helps:
|
Alright, if thats the case fine,
but I don't see any other jobs in the Ui (might be just hidden...) and I can't work with the UI anymore, that's the bug I'd like to describe here, even if the Job takes long/forever/... the rest of the application should just run and you mentioned some "magic" that do this, but I can't see any 'magic' happen here so either the 'magic' is broken or ThreadJob is preventing the 'magic' from being happen and that should be fixed. |
|
The following snippet can be used to reproduce the issue: Steps to reproduce:
Threaddump shows: So this could be reproduced without any complex setup and proofs that there is no magic at all that drives the event-queue (or it is not part of the Job API, or I just can't find it) and the job api statement is true that:
This means, calling beginRule in the UI thread will block this thread until the rule could be acquired. The issue why JDT triggers this is most likely in
to be safe. |
|
You can not expect magic to happen when you do not install the magic UI handlers. |
Calling this from UI thread is invitation for freezes and deadlocks. Quote from javadoc:
So the snippet shows the code works as designed :-) |
|
As long as no one can give a actual reference to some kind of source code I can't try to investigate that, its all open source so whats the reason not simply posting a link here? Beside that, I get the exactly same behavior and call stack as with my inital report, so I really suspect that there is anything more happening...
I always stated thatbut was always told there is some "magic" that prevents this, I haven't found any such magic yet and can hardly guess how it should work... please take a look at the original report you see exactly that sequence of calls:
then down the line: |
It's so complicated that i do not exactly know how it works ("magic") so i can't explain. I posted links to solutions multiple times and you did not try. |
So most probably there is no such magic. e.g. here https://github.com/jukzi/eclipse.platform.ui/blob/329dce1797998f2bca6d9951fd336b08e0e120cc/bundles/org.eclipse.ui.workbench/Eclipse%20UI/org/eclipse/ui/operations/OperationHistoryActionHandler.java#L321-L323 the begin rule is wrapped and if run in the UI thread will exactly trigger this behavior, just from the specification of the JVM there is no chance for any magic happening unless we use byte-code instrumentation in the running code to hot-replace swt classes with some magic stuff.
Feel free to enhance my example with anything that you think is required, the links you posted just try to circumvent some specific cases but don't change how it generally works (or not) there is nothing I can run out of the box ... |
|
I now have added the "magic" parts to my example just insert: still this don't prevent the lock as it only scopes with |
|
I have now added a testcase here eclipse-platform/eclipse.platform.ui#38 there is one existing test, that tests the sync/async exec working and the new one showing where it fails. |
|
I now further debugged the reproducer: As long as one passes a But if not (as I suspect is common) and e.g. pass a So a possible fix would be to add a new method |
|
@laeubi : not sure where exactly do you want wrap what, but In Job framework we have NO idea about SWT threading specials. |
Exactly that method is effectively called, thus if you wait for a rule in UI thread you get the
Yes that's why there is |
This enables the ProgressProvider to decide the instance of the ProgressMonitor used in beginRule / join / suspend operations. This is important if the progressprovider needs to react to certain actions, e.g. in an UI a provider might make sure the UI is responsive or show a "terminate" button even if the job is currently waiting on a rule. Fix eclipse-platform#40
This enables the ProgressProvider to decide the instance of the ProgressMonitor used in beginRule / join / suspend operations. This is important if the progressprovider needs to react to certain actions, e.g. in an UI a provider might make sure the UI is responsive or show a "terminate" button even if the job is currently waiting on a rule. Fix eclipse-platform#40
This enables the ProgressProvider to decide the instance of the ProgressMonitor used in beginRule / join / suspend operations. This is important if the progressprovider needs to react to certain actions, e.g. in an UI a provider might make sure the UI is responsive or show a "terminate" button even if the job is currently waiting on a rule. Fix eclipse-platform#40
This enables the ProgressProvider to decide the instance of the ProgressMonitor used in beginRule / join / suspend operations. This is important if the progressprovider needs to react to certain actions, e.g. in an UI a provider might make sure the UI is responsive or show a "terminate" button even if the job is currently waiting on a rule. Fix eclipse-platform#40
This enables the ProgressProvider to decide the instance of the ProgressMonitor used in beginRule / join / suspend operations. This is important if the progressprovider needs to react to certain actions, e.g. in an UI a provider might make sure the UI is responsive or show a "terminate" button even if the job is currently waiting on a rule. Fix eclipse-platform#40
This enables the ProgressProvider to decide the instance of the ProgressMonitor used in beginRule / join / suspend operations. This is important if the progressprovider needs to react to certain actions, e.g. in an UI a provider might make sure the UI is responsive or show a "terminate" button even if the job is currently waiting on a rule. Fix eclipse-platform#40
This enables the ProgressProvider to decide the instance of the ProgressMonitor used in beginRule / join / suspend operations. This is important if the progressprovider needs to react to certain actions, e.g. in an UI a provider might make sure the UI is responsive or show a "terminate" button even if the job is currently waiting on a rule. Fix #40
There is an annoying problem in m2e see eclipse-m2e/m2e-core#123 even more worse, when this happens one could get eclipse completely stuck:
I can see that the "main" thread is waiting forever to be notified (@iloveeclipse that's what I recently noted about using simple blocking primitives) what seem to never happen (I see no other ThreadJob in the dump).
@jukzi by the way this is a good example that shows that
BusyIndicator.showWhileactually is blocking the UI thread seeat org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:74)in below stack-trace.I have attached a full thread dump here freeze.txt it happened at
The text was updated successfully, but these errors were encountered: