Open sim642 opened 2 years ago
Could not reproduce on WSL by opening, running analyses and closing. Either this has been accidentally fixed or there is some particular step or environment-specific detail required to achieve this.
This is still happening to me on the latest version from @FeldrinH's fork at least: These java processes are not children of any VS Code process, but orphaned and thus direct children of the system init process.
Somehow it's even worse now because the java processes (not their Goblint children!) are running at 100% CPU.
EDIT: Here's the thread dump of one such process: gobpie-orphan-cpu.txt. "adb-server-worker" #54
there seems to have accumulated a lot of CPU time, so that's the new thing that might be causing the CPU usage, but the java process staying alive is probably not caused by that.
One thing that seems to cause such processes is doing "Developer: Reload Window" in VS Code. Maybe it's not handling well the closure of some LSP socket on the VS Code side.
The reason I keep having to reload window is that modifying and saving files for whatever reason stops working for me: no new analysis is ever started.
There seem to be three different problems here:
Closing VSCode sometimes leaves orphaned processes. I think I have observed something similar a couple of times on my computer, but I can't reproduce it reliably. I have some ideas about what might be causing this, but none of them are easy to fix or test.
GobPie process consuming 100% of one CPU core. I have observed this a couple of times on my computer and I think I know what causes this. I think there is a race condition that can lead to the abstract debugger socket file being deleted by the previous GobPie process after the new process has bound to it, which causes it to get stuck in an infinite loop of throwing, catching and logging errors. If I am correct this will be fixed today evening.
The reason I keep having to reload window is that modifying and saving files for whatever reason stops working for me: no new analysis is ever started.
This I have never observed and off the top of my head I can't even concieve how this could possibly happen. If it happens again it might be worth checking the GobPie log output in VSCode, maybe something there could give us a clue.
Small update:
The 100% CPU issue should be fixed on https://github.com/FeldrinH/GobPie/tree/abstract-debugging and should not occur at all on GobPie versions without abstract debugging.
As for orphaned processes, I tried to reload the window and I noticed that old GobPie processes do stay open. I don't know why that is. However, when I close VSCode all GobPie processes are closed with it, so I still can't reproduce the issue itself.
Analysis-on-save breaking I cannot reproduce at all. @sim642 it would probably be a good idea to open a new issue for this, if you can reproduce it consistently on the latest version.
Another update:
The analysis-on-save issue turned out to be that GobPie simply does not trigger an analysis when saving .h or .i files.
This should be fixed once https://github.com/goblint/GobPie/pull/58 is merged.
I have closed all VS Code processes and somehow the java processes from GobPie still keep running:
I'm not sure if this is an issue in GobPie specifically (not allowing itself to be terminated for some reason) or in Magpie more generally.