Intermittent high memory usage and freezing

[andrejp88]

Not completely sure where to submit this, but I saw that the serve-d process was using over 2 GiB of memory so I think it's the culprit.

The past two days, VSCode has been intermittently freezing for a couple of minutes at a time. My whole system is frozen for most of that time too, so it's difficult to figure out what's going on.

I managed to do a bit of debugging. Here is an exceprt from the code-d & serve-d output in VSCode. The clock in my tool bar froze at 13:11:44, and unfroze around 13:13 ish.

2020-03-08T13:11:41.232 [trace] async.d:79:setTimeout Setting timeout for 200 ms
2020-03-08T13:11:41.347 [trace] async.d:79:setTimeout Setting timeout for 200 ms
2020-03-08T13:11:41.473 [trace] async.d:79:setTimeout Setting timeout for 200 ms
2020-03-08T13:11:41.494 [trace] async.d:79:setTimeout Setting timeout for 200 ms
2020-03-08T13:11:41.737 [trace] app.d:79:processRequest Calling provideCodeLens
2020-03-08T13:11:41.747 [trace] app.d:79:processRequest Calling provideCodeActions
stdin(0:0)[error]: Primary expression expected
stdin(0:0)[error]: Expected `}` instead of `EOF`
stdin(0:0)[error]: Expected `}` instead of `EOF`
2020-03-08T13:11:43.631 [trace] async.d:79:setTimeout Setting timeout for 200 ms
2020-03-08T13:11:43.883 [trace] app.d:79:processRequest Calling provideCodeLens
2020-03-08T13:11:44.571 [trace] async.d:79:setTimeout Setting timeout for 200 ms
2020-03-08T13:11:44.829 [trace] app.d:79:processRequest Calling provideCodeLens
2020-03-08T13:11:44.930 [trace] async.d:79:setTimeout Setting timeout for 200 ms
2020-03-08T13:11:45.182 [trace] app.d:79:processRequest Calling provideCodeLens
2020-03-08T13:12:02.750 [trace] app.d:391:main GC run in 3 secs, 135 ms, 717 μs, and 5 hnsecs. Freed 2201451248 bytes (3312829872 bytes allocated, 2927483472 bytes available)
[Info  - 1:12:51 PM] Connection to server got closed. Server will restart.
2020-03-08T13:13:02.147 [trace] app.d:299:main Features fulfilled
2020-03-08T13:13:02.289 [trace] app.d:308:main Interactive HTTP downloads handled via editor
2020-03-08T13:13:02.289 [trace] app.d:314:main Auto-implement interface supports snippets
2020-03-08T13:13:02.289 [trace] app.d:320:main Context snippets handled by serve-d
2020-03-08T13:13:02.289 [trace] app.d:337:main Started reading from stdin
2020-03-08T13:13:02.289 [trace] app.d:341:main RPC started

I'm guessing that part of the reason for the freeze is that the GC frees over 2 GiB of memory, but that seems to take only 15 seconds, whereas my mouse only even started responding around a minute later.

Strange thing is, I had no issues when I last used code-d (about a week ago) and I don't recall seeing a message that anything was updated in the meantime. I don't think I had a system update either.

I did make some changes to my project's dscanner.ini file yesterday but I'm not sure if it's related. I added the following rules:

properly_documented_public_functions="enabled"
useless_initializer="enabled"
assert_without_msg="enabled"
if_constraints_indent="enabled"
long_line_check="enabled"

and the following module filters to exclude a certain file:

long_line_check="- ...
alias_syntax_check="- ...
local_import_check="- ...
unused_variable_check="- ...
unused_parameter_check="- ...

I'm using:
Ubuntu Budgie 19.10
VSCode 1.42.1
code-d 0.22.0
dlang-bundle 0.4.0

Not sure how to check the version of dscanner/dcd/etc. that code-d is using.

[WebFreak001]

it might improve with the new libdparse (awaiting tooling dependency upgrades) which has a new rollback allocator implementation

[dayllenger]

workspace-d#100 dsymbol#144

These patches should improve the situation.

[andrejp88]

Thanks for the reply. How can I get my hands on those changes? Should I change the serve-d update channel to “nightly”?

[WebFreak001]

dsymbol patch will take a while (needs to be updated on all dependencies), workspace-d patch can be applied sooner. I will do some stuff today so it will be in tomorrows nightly

[andrejp88]

I changed my release channel to “nightly”, updated serve-d, and restarted vscode. Unfortunately the issue persists. I’ll wait for the dsymbol updates to see if those help.

In the meantime, I noticed that a couple of smaller projects worked without issue, so I’m guessing that the project that’s crashing grew just large enough that it crossed some threshold.

Might be of interest that the project in question has ~200 unit tests, each of which has at least one template instatiation. There’s also quite a bit of conditional compilation and such going on. Maybe template bloat is causing all that memory usage?

Thanks

[Rojetto]

Just had the same issue with serve-d using 4 gigs of memory, then freeing 2 gigs in one swoop, meanwhile lagging my whole system. It's still using 2 gigs now, which I honestly find somewhat excessive for my pretty small project.

Edit: Seems like the 2 GB was just some kind of buggy state, after restarting VS Code it's now using just a few MBs and working fine. Still would be nice to know what caused this.

[WebFreak001]

@Rojetto can you try using nightly serve-d?

In your user settings change "d.servedReleaseChannel" to "nightly", then reload the window (F1 -> Reload Window)

[Rojetto]

@WebFreak001 Thanks for the suggestion, I was already doing that.

[WebFreak001]

how much memory does your system have in general? It shouldn't be using so much

[Rojetto]

8 GBs in total. I edited my original comment, after restarting restarting VS Code the memory usage has been reduced to a negligible amount. Seems like some other bug brought it to that state 🤷