Skip to content

Infinite build regression in 3.2+ #29326

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
MaceWindu opened this issue Jan 9, 2019 · 8 comments
Closed

Infinite build regression in 3.2+ #29326

MaceWindu opened this issue Jan 9, 2019 · 8 comments
Labels
Needs More Info The issue still hasn't been fully clarified

Comments

@MaceWindu
Copy link

TypeScript Version: 3.2.1 - 3.3.0-dev.20190108

Search Terms:
infinite, build, memory

Code

this is something I need help to narrow down

Expected behavior:

project built successfully as it is done in TSC 3.1.6 and below

Actual behavior:

node.exe allocates memory in ~300Mb chunks and release about 280Mb of it repeatedly leading to OOM after some time
Issue occurs after error check stage, because if project has build errors, it stops after errors repored.

** tsconfig **

tsconfig:

{
    "extends": "../tsconfig",
    "include": [
        "../definitions/ts/*.d.ts"
    ],
    "files": [
        "../definitions/includes.ts",
        "../external/root.ts",
        "root.ts"
    ],
    "compilerOptions": {
        "types": [ "jquery", "kendo-ui", "jstimezonedetect" ]
    }
}

parent tsconfig:

{
    "compileOnSave": false,
    "compilerOptions": {
        "typeRoots": [ "../../../../node_modules/@types/" ],
        "noEmitOnError": true,
        "noUnusedLocals": true,
        "noUnusedParameters": true,
        "removeComments": true,
        "target": "es5",
        "strict": true,
        "noImplicitReturns": true,
        "noFallthroughCasesInSwitch": true,
        "forceConsistentCasingInFileNames": true,
        "noErrorTruncation": true,
        "allowJs": true,
        "lib": [
            "dom",
            "es5"
        ],
        "stripInternal": true,
        "declaration": false,
        "jsx": "react",
        "jsxFactory": "Templates.compile"
    }
}

Guys, I think I need some help narrowing down this issue/repro. I can attach to build using debugger, but because it looks like some iterative process and call stack doesn't give me any idea where to look as I'm not really familiar with tsc internals - I think I need some directions what I should check.

Random stacktraces:

    at updateLineCountAndPosFor (c:\Perforce\node_modules\typescript\lib\typescript.js:11048:42)
    at Object.write (c:\Perforce\node_modules\typescript\lib\typescript.js:11066:17)
    at writePunctuation (c:\Perforce\node_modules\typescript\lib\typescript.js:84291:20)
    at emitTypeLiteral (c:\Perforce\node_modules\typescript\lib\typescript.js:82616:13)
    at pipelineEmitWithHint (c:\Perforce\node_modules\typescript\lib\typescript.js:82003:32)
    at emit (c:\Perforce\node_modules\typescript\lib\typescript.js:81882:13)
    at emitFunctionType (c:\Perforce\node_modules\typescript\lib\typescript.js:82574:13)
    at pipelineEmitWithHint (c:\Perforce\node_modules\typescript\lib\typescript.js:81995:32)
    at emit (c:\Perforce\node_modules\typescript\lib\typescript.js:81882:13)"
    at writeTrailingSemicolon (c:\Perforce\node_modules\typescript\lib\typescript.js:84293:40)
    at emitPropertySignature (c:\Perforce\node_modules\typescript\lib\typescript.js:82476:13)
    at pipelineEmitWithHint (c:\Perforce\node_modules\typescript\lib\typescript.js:81971:32)
    at emit (c:\Perforce\node_modules\typescript\lib\typescript.js:81882:13)
    at emitNodeList (c:\Perforce\node_modules\typescript\lib\typescript.js:84233:21)
    at emitList (c:\Perforce\node_modules\typescript\lib\typescript.js:84108:13)
    at emitTypeLiteral (c:\Perforce\node_modules\typescript\lib\typescript.js:82615:13)
    at pipelineEmitWithHint (c:\Perforce\node_modules\typescript\lib\typescript.js:82003:32)
    at emit (c:\Perforce\node_modules\typescript\lib\typescript.js:81882:13)"
    at pipelineEmitWithHint (c:\Perforce\node_modules\typescript\lib\typescript.js:81931:38)
    at emit (c:\Perforce\node_modules\typescript\lib\typescript.js:81882:13)
    at emitNodeList (c:\Perforce\node_modules\typescript\lib\typescript.js:84233:21)
    at emitList (c:\Perforce\node_modules\typescript\lib\typescript.js:84108:13)
    at emitTypeLiteral (c:\Perforce\node_modules\typescript\lib\typescript.js:82615:13)
    at pipelineEmitWithHint (c:\Perforce\node_modules\typescript\lib\typescript.js:82003:32)
    at emit (c:\Perforce\node_modules\typescript\lib\typescript.js:81882:13)
    at emitFunctionType (c:\Perforce\node_modules\typescript\lib\typescript.js:82574:13)
    at pipelineEmitWithHint (c:\Perforce\node_modules\typescript\lib\typescript.js:81995:32)"
@MaceWindu
Copy link
Author

Full stack...
o_o

@MaceWindu
Copy link
Author

I've looked at full stack again and for me it looks like problem starts from reportNonexistentProperty call. Then I probably will be able to narrow down repro

@MaceWindu
Copy link
Author

Looks like it is related to noErrorTruncation option. Setting it to false makes build pass again (without errors!)

@MaceWindu
Copy link
Author

Ok, repro is easy:
root.ts

/// <reference path="jquery.js" />
  • unminified jquery.js v3.3.1

@MaceWindu
Copy link
Author

Actually, I think real problem here is that compiler spends insane (or significant in case of noErrorTruncation:false) amount of resources to generate messages, which nobody use.

@weswigham weswigham added the Needs Investigation This issue needs a team member to investigate its status. label Jan 9, 2019
@weswigham
Copy link
Member

weswigham commented Jan 9, 2019

Yeah... error truncation exists for a reason~ types can become arbitrarily complex (and arbitrarily complex to print) so the cutoff can actually become important for perf reasons. Still, I am curious what in the jquery JS file would make us generate such a complex type - normally this kinda thing only happens when someone is doing higher order type system algebra (which a JS file isn't usually capable of).

@RyanCavanaugh RyanCavanaugh added Needs More Info The issue still hasn't been fully clarified and removed Needs Investigation This issue needs a team member to investigate its status. labels Aug 23, 2019
@RyanCavanaugh
Copy link
Member

We'd really need a repro to assist further

@MaceWindu
Copy link
Author

Retested it and it works fine again starting from v3.5.1.
just in case attached files to reproduce it

issue29326.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs More Info The issue still hasn't been fully clarified
Projects
None yet
Development

No branches or pull requests

3 participants