Symbol table corruption leads to runaway memory usage

[RyanCavanaugh]

TypeScript Version: 2.8

Search Terms: symbol corrupt

Code

Note: This only repros in VS (verified in an external project but have not verified in an inferred project yet). I have not yet determined why this is the case.

You will need three files

file1.js

blah.prototype = {
    m: "q"
};

file2.d.ts

declare class blah { }

file3.js

/* do editing here */

Make about 70 edits in file3.js without changing file1.js or file2.d.ts

Expected behavior: Stable memory usage

Actual behavior: Eventually, memory usage climbs exponentially

Root cause here is that in this code:

                if ((source.flags | target.flags) & SymbolFlags.JSContainer) {
                    const sourceInitializer = getJSInitializerSymbol(source);
                    const targetInitializer = getJSInitializerSymbol(target);

sourceInitializer and targetInitializer are the same object and we end up copying the same declarations array into itself, pushing more objects into the (supposedly immutable!)
symbol tables from the SourceFiles and doubling the array length the next time around.

You can verify this hypothesis by stopping before the process OOMs, editing file2.d.ts and file1.js - node will quickly GC back down to the baseline memory consumption because we create a fresh symbol table when the file is edited.

I also can't get this to repro via commandline means, so possibly something else fishy is going on.

@sandersn - I applied the bail-out patch we discussed earlier but the problem is that we still grow the array linearly during the top level of each global merging pass (since we're still doing some writing to the original symbol table). This isn't as bad but is still going to cause problems in longer editing sessions.

Playground Link: n/a

[RyanCavanaugh]

I will make an LS build tomorrow that logs this state to the ts server log along with symbol locations so we can collect usable repros from the other people that hit this

[RyanCavanaugh]

Both known repros listed at #24050 (comment)

[gs-akhan]

Hi, The npm says the version is 2.8.3. When will it be updated ?

Thanks

[sandersn]

@gs-akhan typescript@rc is on 2.9 now and I think the official release of 2.9 is any day now.

Are you hitting this issue? If so, (1) which editor are you using (2) which libraries are you using?

[gs-akhan]

Hi, No I am not facing any issue. I just upgraded my production app from TS 2.0 to 2.8.3, I was just wondering if I can take this fix along and migrate to 2.8.4 Thanks

…

On Wed, May 30, 2018 at 9:10 PM Nathan Shively-Sanders < ***@***.***> wrote: @gs-akhan <https://github.com/gs-akhan> ***@***.*** is on 2.9 now and I think the official release of 2.9 is any day now. Are you hitting this issue? If so, (1) which editor are you using (2) which libraries are you using? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#24015 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFYnVnluk76iEoGcK541P4rrMb3xKnFeks5t3r2FgaJpZM4T5Y_T> .

[sandersn]

@gs-akhan This issue only manifests in the editor, and only with projects that contain javascript, and only with projects that introduce globals instead of using modules for everything. If you are upgrading a project from 2.0, it's unlikely that you have javascript because --allowJs was only introduced in 1.8.