Terminated tasks stay hanging in Progress view

[iloveeclipse]

Since some latest changes on Progress view in 4.26 I observe various job entries staying "hanging" in the Progress view.
I can click on "Black cross" icon on the entry to "remove it from view", they are removed ... but appear again as soon as I click on "Remove All" button in the Progress view.

Before:

after "remove from view":

and back to live after "Remove All":

I assume #308 could be the root cause for the regression.

[iloveeclipse]

zombies_in_progress_view.mp4

@jukzi : could you please check this?
I assume something with handling of cancelled job entries is wrong now.

[jukzi]

How to reproduce? I do not see such behavior even if i cancel jobs or press the remove all button. do you have "Show slepping" preferences enabled or disabled?

[iloveeclipse]

How to reproduce?

Try to work with latest SDK builds :-)
Sooner or later some job will "hang" in the Progress view.

My typical workflow includes starting latest SDK nightly build with existing SDK workspace with almost all of SDK projects opened. That alone produces lot of build related jobs because of the platform change.
After that "pull all" on all SDK repos produces another batch of jobs.
And typically I have to pull & debug PR's, which again causes various jobs.
Somewhere in that workflow some job will "hang".

do you have "Show slepping" preferences enabled or disabled?

Enabled.

[jukzi]

I got one case where it showed the IOConsolePartitioner$QueueProcessingJob 3 times, and got the same behavior like you.
I "removed" all items from the view and took a heapdump.
org.eclipse.ui.internal.progress.FinishedJobs was empty

and DetailedProgressViewer.jobItemControls was empty:

The GC root of the 3 Jobs was org.eclipse.ui.internal.progress.ProgressManager.runnableMonitors

I don't think this is related to my changes in the DetailedProgressViewer/JobInfo - it's just that ProgressManager says those jobs are still there and he does not use the JobInfo but the Job as key.

My best guess is that the cancel event may be sometimes send in a strange order - (like the join() problem). And any further cancel() events from ProgressInfoItem.cancelOrRemove() (the action of the button) will be ignored from org.eclipse.core.internal.jobs.JobManager.cancel(InternalJob).

One might add the ProgressManager.checkForStaleness(Job) to org.eclipse.ui.internal.progress.ProgressManager.refreshJobInfo(JobInfo)? Hard to say because i have no deterministic reproducer.

[iloveeclipse]

it's just that ProgressManager says those jobs are still there and he does not use the JobInfo but the Job as key.

My best guess is that the cancel event may be sometimes send in a strange order - (like the join() problem).

May be same problem as eclipse-jdt/eclipse.jdt.debug#137