Memory leak on watcher dispose

[Llorx]

When I run this code:

var i = 0;
var webpack = require("webpack");
function c() {
    var compiler = webpack({
        context: __dirname,
        entry: "./main3.ts",
        output: {
            filename: 'bundle.js',
            path: '/'
        },
        resolve: {
            extensions: ["", ".webpack.js", ".web.js", ".ts", ".tsx", ".js"]
        },
        module: {
            loaders: [{
                test: /\.tsx?$/,
                loader: "ts-loader"
            }],
        }
    });
    compiler.plugin("compile", () => {
        console.log("cmp", i++);
    });
    return compiler.watch({
        aggregateTimeout: 333
    }, (err, stats) => {
        setTimeout(() => {
            oldc.close();
            oldc = c();
        }, 33);
    });
}
oldc = c();

Having as main3.ts contents simply a bunch of console.log (about 10k, for testing), without any dependencies of anything, after some time I get a "process out of memory" error.

Don't happens if I change the main3.ts extension to js (so the loader is not used) and also don't happens with awesome-typescript-loader (you see the memory going up and down, instead of all the way up), so I guess is a ts-loader problem.

[johnnyreilly]

Which version are you using? Does this apply to the latest version? If you could spend some time on this it would be greatly appreciated!

[Llorx]

Of, forgot to say... silly me xD webpack 1.14.0 and ts-loader 1.3.3

I guess they are the latest. Just made npm install webpack and ts-loader

Also, if someone can copypaste the script and confirm that this happens to him also, would be nice.

[johnnyreilly]

If someone else can take a look at this (btw not totally sure this is an issue or not yet) that'd be awesome. If not I'll probably close this issue; I don't have time to look into it myself and I'm not experiencing the issue described

[johnnyreilly]

Perhaps related to #421

[johnnyreilly]

If you add in the loader options plugin as suggested in #421 does this resolve the issue?

[Llorx]

As far as I can remember, I had one plugin defining a production environment variable, but I removed it from the script above. This evening I'll check/try it.

[johnnyreilly]

thanks

[Llorx]

Ok, I was not using LoaderOptionsPlugin.

Upgraded to webpack 2.2.0-rc.1 (I was on 1) and tested exactly with this script:

var i = 0;
var path = require("path");
var webpack = require("webpack");
function c() {
    var compiler = webpack({
        context: path.join(__dirname),
        entry: "./main3.ts",
        output: {
            filename: 'bundle.js',
            path: '/'
        },
        resolve: {
            extensions: [".ts", ".tsx", ".js"]
        },
        module: {
            loaders: [
                {
                    test: /\.tsx?$/,
                    loader: "ts-loader"
                }
            ]
        },
        plugins: [
            new webpack.LoaderOptionsPlugin({ options: {} })
        ]
    });
    compiler.plugin("compile", function () {
        console.log("cmp", i++);
    });
    return compiler.watch({
        aggregateTimeout: 333
    }, (err, stats) => {
        setTimeout(() => {
            oldc.close();
            oldc = c();
        }, 33);
    });
}
oldc = c();

The main3.ts is a 10 Kb file containing nothing more than console.log("test");console.log("test");cons....

The tsconfig.json file contains nothing more than:

{
    "compilerOptions": {
        "jsx": "react",
        "module": "commonjs",
        "sourceMap": true,
        "target": "es5"
    }
}

Received the same error after some minutes (cmp 23):

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory

In short, these are my versions:

• ts-loader 1.3.3
• webpack 2.2.0-rc.1
• node v4.4.7

[johnnyreilly]

And if you add the loader options plugin does it resolve the issue?

[johnnyreilly]

Like this:

new LoaderOptionsPlugin({      
   options: {       
     resolve: {
       extensions: ['.ts', '.tsx', '.js', 'jsx']
     }  
   }        
 })     

[Llorx]

I'm not sure where to add it. In the code above it is added inside the plugins: array.

Now I changed it to

plugins: [
    new webpack.LoaderOptionsPlugin({
        options: {
            resolve: {
                extensions: ['.ts', '.tsx', '.js', 'jsx']
            }
        }
    })
]

And still having the problem.

[johnnyreilly]

Very strange. Thanks for trying. Could you try using ts-loader 1.3.1 and see if it's still an issue?

[Llorx]

`-- ts-loader@1.3.1
  `-- enhanced-resolve@0.9.1
    +-- memory-fs@0.2.0
    `-- tapable@0.1.10

And still receiving the problem at cmp 23.

You said you don't have this problem when copypasting the script? Could this be a TypeScript version problem then? Or a dependant module? (I had memory-fs already installed, so maybe I have a different version than you).

EDIT: Well, we can say that typescript 2.1.4 manages memory better than 2.0.10, as I updated it and can reach cmp 29 instead of 23, but still crashing.

[johnnyreilly]

I haven't used your script. I've been running ts-loader in watch mode for days at a time and watching the memory. It stays pretty static. In normal usage there's no sign that I've picked up on of a memory leak. Which is good. But confusing

[Llorx]

Oh, the thing is that I'm closing the watcher and opening a new one on each loop (Was the main reason of this test). Watcher could be fine. The problem can be when disposing it.

[johnnyreilly]

That's interesting. Since watch mode only typically ends when the process terminated and all resources seem to be released then that means I'm a little less concerned. Still like to get to the bottom of this though

[Llorx]

Let's see if someone (or me when I get forced to use ts-loader instead of awesome-typescript-loader) finds something

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Closing as stale. Please reopen if you'd like to work on this further.