jukzi
commented
2 years ago 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.."
Closed laeubi closed 2 years ago
jukzi
commented
2 years ago 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.."
jukzi
commented
2 years ago actually this whole refactoring issue is just a duplicate of Bug 578871
laeubi
commented
2 years ago 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:
if (state == Job.RUNNING && canBlock) {
blockingJob.jobStateLock.wait();
} else if (state != Job.NONE) {
blockingJob.jobStateLock.wait(250);
}Whatever it does, my eclipse is stuck,
yes, that why i demand to fix it: https://github.com/eclipse-jdt/eclipse.jdt.ui/pull/19
laeubi
commented
2 years ago it's not blocking. its a wait(250) =>will update UI at least every 250ms,
I do not see any code in this while loop that actually updates the UI, that is calling Display.readAndDispatch anywhere, can you direct me to the place where this happens?
jukzi
commented
2 years ago yea, thats like magic in the blocker handler. How about you test my proposed fix for your situation?
laeubi
commented
2 years ago yea, that's like magic in the blocker handler
Can you give a code reference to this magic?
jukzi
commented
2 years ago use the patch and set a breakpoint at the method you search for.
laeubi
commented
2 years ago just a duplicate of Bug 578871
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 ThreadJob.waitForRun as at this time there are no other jobs, for what is it waiting for?
jukzi
commented
2 years ago 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: https://github.com/eclipse-platform/eclipse.platform.resources/pull/45
laeubi
commented
2 years ago You complain "The Progress View freezes" and on the other hand say "This is not an UI freeze". contradictory.
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 :-)
vogella
commented
2 years ago 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?
vogella
commented
2 years ago 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.
jukzi
commented
2 years ago Please separate the Problems: 1.) UI freezes 2.) autobuild is repeating.
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? 1) is bug 578871 - as far as its during refactor while autobuild is running and 2) is probably not a platform bug
laeubi
commented
2 years ago Please separate the Problems: 1.) UI freezes 2.) autobuild is repeating.
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.
jukzi
commented
2 years ago 3.) Job is never run
But the stacktrace you posted is as in bug 578871. It not a bug but a feature that a bug is never run as if the job has a conflicting IScheduleRule. during autobuild the whole workspace i locked. there will be no other job with any resource rule started until autobuild finished
vogella
commented
2 years ago Maybe the job tracing helps:
laeubi
commented
2 years ago It not a bug but a feature that a bug is never run as if the job has a conflicting IScheduleRule
Alright, if thats the case fine,
here will be no other job with any resource rule started until autobuild finished
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.
laeubi
commented
2 years ago The following snippet can be used to reproduce the issue:
final ISchedulingRule rule = new TestRule();
CountDownLatch countdown = new CountDownLatch(1);
Job job = Job.create("Runs until notified", new ICoreRunnable() {
@Override
public void run(IProgressMonitor monitor) {
monitor.beginTask("Just waiting....", 100);
Job.getJobManager().beginRule(rule, null);
try {
countdown.await();
} catch (InterruptedException e) {
} finally {
Job.getJobManager().endRule(rule);
monitor.done();
}
}
});
job.schedule();
Display display = new Display();
Shell shell = new Shell(display);
shell.setLayout(new FillLayout());
shell.setText("Hello World");
shell.setSize(200, 200);
Button button = new Button(shell, SWT.PUSH);
button.setText("Schedule me");
button.addSelectionListener(new SelectionListener() {
@Override
public void widgetSelected(SelectionEvent e) {
button.setEnabled(false);
Job.getJobManager().beginRule(rule, null);
countdown.countDown();
Job.getJobManager().endRule(rule);
button.setText("Done!");
}
@Override
public void widgetDefaultSelected(SelectionEvent e) {
}
});
shell.open();
while (!shell.isDisposed()) {
while (display.readAndDispatch()) {
}
display.sleep();
}
display.dispose();Steps to reproduce:
Display#readAndDispatch and eg resize the dialog or something and you should see the method is triggered.Display#readAndDispatch (will never trigger)Threaddump shows:
Thread [main] (Suspended)
waiting for: Object (id=92)
Object.wait(long) line: not available [native method]
Object.wait() line: 328
ThreadJob.waitForRun(ThreadJob, IProgressMonitor, InternalJob) line: 322
ThreadJob.joinRun(ThreadJob, IProgressMonitor) line: 208
ImplicitJobs.begin(ISchedulingRule, IProgressMonitor, boolean) line: 95
JobManager.beginRule(ISchedulingRule, IProgressMonitor) line: 315
SyncExecWhileUIThreadWaitsForRuleTest$2.widgetSelected(SelectionEvent) line: 89
TypedListener.handleEvent(Event) line: 252
EventTable.sendEvent(Event) line: 89
Display.sendEvent(EventTable, Event) line: 5863
Button(Widget).sendEvent(Event) line: 1529
Display.runDeferredEvents() line: 5094
Display.readAndDispatch() line: 4546 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:
f the rule conflicts with another rule currently running in another thread, this method blocks until there are no conflicting rules.
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 OperationHistoryActionHandler.run because that method forces to be run in the UI thread and if operation is not IAdvancedUndoableOperation2 and return runInBackground=truewill execute the whole operation in the UI thread and thus those operation must:
to be safe.
jukzi
commented
2 years ago You can not expect magic to happen when you do not install the magic UI handlers.
iloveeclipse
commented
2 years ago JobManager.beginRule
Calling this from UI thread is invitation for freezes and deadlocks. Quote from javadoc:
Begins applying this rule in the calling thread. If the rule conflicts with another rule currently running in another thread, this method blocks until there are no conflicting rules.
So the snippet shows the code works as designed :-)
laeubi
commented
2 years ago 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...
Calling this from UI thread is invitation for freezes and deadlocks.
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:
at org.eclipse.core.internal.jobs.ThreadJob.waitForRun(ThreadJob.java:324) at org.eclipse.core.internal.jobs.ThreadJob.joinRun(ThreadJob.java:208) at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:95) at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:311)
then down the line: org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:74) and then look at how BusyIndicator.showWhile is implemented and how TimeTriggeredProgressMonitorDialog call it there is absolutely no chance that the Ui Thread is ever running as I reproduced with my example in a more simple way, and as I noted recently in a review and it was deemed invalid because the "magic"....
jukzi
commented
2 years ago 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?
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.
laeubi
commented
2 years ago It's so complicated that i do not exactly know how it works ("magic")
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.
you did not try
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 ...
laeubi
commented
2 years ago I now have added the "magic" parts to my example just insert:
IJobManager manager = Job.getJobManager();
Display display = new Display();
UILockListener listener = new UILockListener(display);
manager.setLockListener(listener);
UISynchronizer synchronizer = new UISynchronizer(display, listener);
display.setSynchronizer(synchronizer);still this don't prevent the lock as it only scopes with sync/async exec calls from withing locks but can't interfere already running code unless the code returns to the UI-Loop what is simply not happening here.
laeubi
commented
2 years ago I have now added a testcase here https://github.com/eclipse-platform/eclipse.platform.ui/pull/38 there is one existing test, that tests the sync/async exec working and the new one showing where it fails.
laeubi
commented
2 years ago I now further debugged the reproducer:
As long as one passes a null or NullProgressMonitor to the JobManager.beginRule everything works perfectly fine, because then the JobManager calls the ProgressProvider, what is a org.eclipse.ui.internal.progress.ProgressManager what in turn creates a EventLoopProgressMonitor that then drives the event queue.
But if not (as I suspect is common) and e.g. pass a SubMonitor (many calls do that) then this is not working and the monitor itself is used and the event queue is stuck and UI freezes.
So a possible fix would be to add a new method ProgressProvider#wrapMonitor(IProgressMonitor)that is called here and wraps any monitor in a EventLoopProgressMonitor.
iloveeclipse
commented
2 years ago @laeubi : not sure where exactly do you want wrap what, but EventLoopProgressMonitor should only be used if the thread that created the progress monitor is supposed to drive UI queue (== UI thread), see for example org.eclipse.ui.internal.progress.ProgressManager.getDefaultMonitor().
In Job framework we have NO idea about SWT threading specials.
laeubi
commented
2 years ago see for example org.eclipse.ui.internal.progress.ProgressManager.getDefaultMonitor()
Exactly that method is effectively called, thus if you wait for a rule in UI thread you get the EventLoopProgressMonitor else a plain NullProgressMonitor and everything works "like magic", except you pass a non null (progres) monitor...
In Job framework we have NO idea about SWT threading specials.
Yes that's why there is org.eclipse.core.runtime.jobs.ProgressProvider what ProgressManager implements so thats the place where a #wrapMonitor could be provided (that simply returns IProgressMonitor.nullSafe(IProgressMonitor) as a default, then ProgressManager can override that method and return a EventLoopProgressMonitor if called from UI thread.
There is an annoying problem in m2e see https://github.com/eclipse-m2e/m2e-core/issues/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